BadGarbage CVE-2026-53361: root y fuga de contenedor

El 10 de agosto de 2026 apareció en GitHub un exploit funcional para BadGarbage, y de golpe un CVE que había pasado casi inadvertido desde julio se convirtió en un problema operativo de primer orden. La demo es incómoda de leer: un proceso sin privilegios, corriendo dentro de un contenedor Docker por defecto, termina siendo root del host en menos de medio minuto. Si administrás servidores Linux con contenedores en producción, esto te toca.

BadGarbage es el apodo de CVE-2026-53361, una vulnerabilidad de tipo use-after-free por race condition en el garbage collector de sockets AF_UNIX del kernel de Linux. La descubrió y documentó la comunidad de seguridad del kernel; permite que un usuario local sin privilegios —incluido un proceso dentro de un contenedor— escale a root en la máquina anfitriona. El NVD la publicó el 4 de julio de 2026 con una puntuación CVSS de 7.1.

¿Por qué un CVE de julio se volvió urgente recién en agosto de 2026?

BadGarbage (CVE-2026-53361): de PoC público a root en 30 segundos

Porque hasta el 10 de agosto no existía código de explotación público, y sin PoC un CVE de kernel es una nota técnica más. El NVD publicó CVE-2026-53361 el 4 de julio de 2026, pero el detonante operativo fue la liberación del exploit funcional del investigador sgkdev en el repositorio sgkdev/bad_garbage. A partir de ahí, cualquiera con acceso local a un sistema vulnerable tiene una ruta reproducible hacia root.

Esa distancia entre "hay un CVE" y "hay un PoC" es exactamente donde cambia el cálculo de riesgo. Mientras la falla es teórica, la mayoría de los equipos la dejan para la próxima ventana de mantenimiento. Cuando el exploit está en GitHub y funciona a la primera, el reloj para parchear se mide en días, no en semanas. La sincronización acá fue estrecha: el PoC salió el 10 de agosto y algunos proveedores recién tuvieron kernel parcheado disponible una semana después.

¿Cómo funciona la falla en el garbage collector de AF_UNIX?

BadGarbage es un use-after-free provocado por una carrera entre una lectura con MSG_PEEK y el recolector de basura de sockets Unix del kernel. El GC lleva una contabilidad de qué sockets siguen "en vuelo" para decidir cuáles liberar; una operación MSG_PEEK concurrente toma una referencia a un socket que esa contabilidad nunca cuenta. Resultado: el recolector libera un socket que todavía está vivo y deja un sk_buff colgando.

El corazón del bug está en la bandera gc_in_progress dentro de unix_gc(). Según la documentación del PoC, esa bandera puede leerse como false en pleno recorrido del recolector, así que el peek se cuela y la ventana de carrera queda abierta. Una vez que tenés memoria del kernel liberada pero aún referenciada, el camino habitual es transformar ese use-after-free en primitivas de lectura/escritura arbitraria de memoria del kernel, y desde ahí a control total.

El propio nombre oficial del fix lo resume sin vueltas. La descripción del NVD para CVE-2026-53361 es literalmente "af_unix: Set gc_in_progress to true in unix_gc()": el parche upstream (commit d82ba05263c6) hace que el recolector se marque como en progreso de forma confiable, cerrando la ventana. El PoC publicado ataca la variante de vector único, usando solo MSG_PEEK, y está pensado para máquinas con pocos núcleos (2 a 7 CPUs), donde la carrera es más fácil de ganar.

¿Qué versiones del kernel de Linux están afectadas?

Están afectadas amplias franjas de la serie 6.x del kernel: cualquier build previo a los parches específicos que arreglan la carrera. Según el rango de versiones del NVD, la falla toca ramas desde la 6.1.141 hasta correcciones puntuales en 6.6, 6.9–6.12, 6.13–6.18 y 6.19. En la práctica, si corrés un kernel 6.x reciente sin la actualización de seguridad, asumí que estás expuesto hasta verificar lo contrario.

Estos son los cortes de versión que aparecen en las fuentes públicas. Verificá siempre contra el aviso de tu distribución, porque cada una backportea el fix a su propio numbering:

Rama del kernel	Estado según las fuentes
Stable 6.12	Vulnerable hasta 6.12.94; corregido en 6.12.95
Ubuntu 24.04 HWE (6.17)	Vulnerable hasta 6.17.0-41
Debian trixie (6.12)	Vulnerable hasta 6.12.94+deb13-cloud-amd64
RHEL 10 / AlmaLinux 10 (6.12)	Afectado; requiere kernel de seguridad actualizado
CloudLinux 10	Corregido en `kernel-6.12.0-211.47.1.el10_2` o superior

Kernels más viejos y de vida larga, del estilo 3.10, 4.18 o 5.14, quedan afuera del rango vulnerable: la lógica de MSG_PEEK que rompe la contabilidad del GC es de la era 6.x. Eso no es excusa para no actualizar, pero acota el problema.

¿Por qué esto rompe el aislamiento de los contenedores?

Porque un contenedor comparte el kernel con el host, y BadGarbage es una falla del kernel. Los sockets AF_UNIX y el syscall MSG_PEEK están disponibles dentro de un contenedor por defecto, sin capacidades extra ni --privileged. Cuando el use-after-free te da control del kernel, ese control es del único kernel que hay: el del host. El namespace del contenedor deja de ser una frontera.

El aviso de CloudLinux es explícito sobre la velocidad del ataque: "en nuestro propio laboratorio, el exploit público llevó un contenedor Docker por defecto a root completo del host en el kernel de AlmaLinux 10… a la primera corrida, en menos de treinta segundos, sin privilegios agregados". Para un clúster de Kubernetes multi-tenant o cualquier plataforma que corre cargas de terceros en contenedores, eso convierte a un pod comprometido en un compromiso del nodo entero.

Y hay un detalle que empeora el panorama operativo: no hay mitigación en tiempo de ejecución. La respuesta del propio aviso de CloudLinux a la pregunta de si existe un workaround es directa: "No, no hay mitigación de runtime para esta vulnerabilidad". No hay sysctl que apagar, ni módulo, ni opción de build, y SELinux no impide la explotación. El único remedio real es el kernel parcheado.

¿Qué podés hacer hoy para protegerte?

La acción concreta es una sola: actualizar el kernel a una versión que incluya el fix y reiniciar. Todo lo demás es contención mientras llegás a ese reinicio. Concretamente:

Actualizá el kernel y reiniciá. Instalá la versión parcheada de tu distribución (por ejemplo, kernel-6.12.0-211.47.1.el10_2 o superior en CloudLinux 10, o 6.12.95+ en stable) y reiniciá: un fix de kernel no aplica hasta que arranca el kernel nuevo. Si usás live patching, verificá que el vendor haya publicado el parche en caliente.
Priorizá los hosts que corren cargas no confiables. Nodos de Kubernetes multi-tenant, runners de CI/CD, plataformas que ejecutan código de clientes: ahí el vector "proceso local sin privilegios" ya está del lado de adentro por diseño. Van primero en la cola de parcheo.
Auditá qué kernel corren tus nodos, no qué imagen. El riesgo está en el kernel del host, no en la imagen del contenedor. Un uname -r por nodo te dice más que revisar los Dockerfile.
Endurecé el acceso local mientras parcheás. Reducí quién puede ejecutar procesos arbitrarios en esos hosts. No es una mitigación de la falla —cualquier código local vulnera— pero achica la superficie de quién puede disparar el exploit.
No esperes a que esté en el catálogo KEV. Con PoC público y funcional, el análisis de riesgo ya no depende de la puntuación CVSS: tratalo como explotación activa hasta demostrar lo contrario.

Un patrón que se repite: la familia de bugs del GC de AF_UNIX

BadGarbage no es un accidente aislado, sino el tercer capítulo de una saga en el mismo subsistema. La documentación del PoC lista tres correcciones distintas sobre esta clase de falla en el garbage collector de AF_UNIX: cbcf01128d0a (CVE-2021-0920), e5b31d988a41 (CVE-2026-23394) y ahora d82ba05263c6 (CVE-2026-53361). Es el mismo tipo de carrera reapareciendo por caminos ligeramente distintos.

Para un developer o un SRE, la lección práctica es que el subsistema de sockets Unix del kernel es un terreno recurrente de use-after-free, y que un solo parche rara vez cierra la categoría entera. Vale la pena tratar estos avisos como una serie, no como eventos sueltos: cuando aparece uno nuevo del GC de AF_UNIX, la pregunta correcta no es solo "¿estoy parcheado para este?" sino "¿tengo el proceso para parchear el próximo rápido?".

Si te interesa el patrón "pocos bytes al lugar equivocado y sos root", esta nota se lee bien junto a nuestra cobertura de Copy Fail (CVE-2026-31431), otro camino de escalada local en el kernel de Linux que publicamos antes. Y en el mismo ciclo apareció un primo cercano de escape de contenedor por fragmentación IPv6 (CVE-2026-53362, aviso RHSB-2026-009 de Red Hat), señal de que agosto de 2026 fue un mes cargado para el aislamiento de contenedores.

Preguntas frecuentes

¿Qué es exactamente BadGarbage (CVE-2026-53361)?

Es un use-after-free por race condition en el garbage collector de sockets AF_UNIX del kernel de Linux. Una lectura con MSG_PEEK toma una referencia que el recolector no contabiliza, así que el kernel libera un socket todavía en uso y deja memoria colgando explotable.

¿Qué puntuación CVSS tiene?

El NVD le asignó 7.1 (alta), con vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H. La "L" en el vector de ataque indica que requiere acceso local: no se explota de forma remota por red, pero un proceso dentro de un contenedor ya cuenta como local.

¿Se puede explotar desde dentro de un contenedor sin privilegios?

Sí. El PoC público escala desde un contenedor Docker por defecto —sin --privileged ni capacidades extra— hasta root del host. El contenedor comparte el kernel con el anfitrión, y la falla vive en ese kernel, así que el aislamiento del namespace no protege.

¿Hay alguna mitigación que no sea actualizar el kernel?

No. El aviso de CloudLinux confirma que no existe mitigación en tiempo de ejecución: ni sysctl, ni módulo, ni opción de build, y SELinux no lo previene. La única solución es instalar el kernel parcheado y reiniciar.

¿Cómo sé si mi servidor está afectado?

Corré uname -r y compará el número de versión contra el aviso de tu distribución. Si estás en una rama 6.x anterior a la corrección específica (por ejemplo, previo a 6.12.95 en stable), asumí que sos vulnerable hasta actualizar. Kernels 3.10, 4.18 o 5.14 quedan fuera del rango.

¿Desde cuándo hay exploit público?

Desde el 10 de agosto de 2026, cuando el investigador sgkdev publicó un PoC funcional en GitHub. El CVE existía desde el 4 de julio, pero recién con el exploit disponible pasó a ser una prioridad de parcheo urgente.