Hace un par de semanas, escribí sobre Copy-Fail (CVE-2026-31431) y cómo el enfoque de defensa en profundidad de Red Hat OpenShift evitó que los contenedores se escaparan a pesar de que el kernel era vulnerable. Dediqué tiempo a intentar salir de un contenedor de OpenShift, obtuve acceso de root dentro del pod casi de inmediato y, aun así, no pude escapar al host. La vulnerabilidad del kernel era real. La ruta de explotación era real. Las defensas resistieron.
Mientras terminaba este artículo, otra variante relacionada, DirtyDecrypt (CVE-2026-31635), comenzó a circular públicamente junto con el debate sobre las amenazas y la cobertura de la prueba de concepto. En ese momento, analizamos 4 vulnerabilidades importantes de escalada de privilegios de Linux en aproximadamente 14 días, y todas abusaban de variaciones del mismo patrón general.
Esa es la parte que más me importa.
En cierto punto, dejas de considerarlos como CVE aislados y empiezas a reconocer un problema sistémico. Diferentes subsistemas. Diferentes rutas de explotación. El mismo concepto subyacente: manipular el comportamiento de copia en escritura dentro de la memoria caché de la página del kernel, corromper archivos supuestamente inmutables y escalar los privilegios.
Si ejecutas una infraestructura de producción en este momento, darte cuenta de eso cambia la conversación con bastante rapidez. Buscar CVE individuales de uno en uno empieza a parecerse menos a una estrategia de seguridad y más a intentar atrapar copos de nieve con la lengua durante una avalancha. El resultado final no es agradable.
Lo que importa es si tu arquitectura sigue siendo resiliente cuando aparezca inevitablemente la próxima variante.
Porque en este punto, probablemente lo hará.
Distintos CVE, mismo patrón
En las últimas 2 semanas, los investigadores revelaron varias vulnerabilidades relacionadas: Copy-Fail se dirige a la manipulación general de la memoria caché de la página; Dirty Frag se traslada a las rutas de ESP/XFRM y RxRPC; Fragnesia se dirige a ESP-in-TCP y ahora DirtyDecrypt surge públicamente en torno a rxgk. Los detalles de la implementación varían, pero la filosofía general de explotación se mantiene notablemente uniforme. Los investigadores encuentran una debilidad conceptual en un área del código de red del kernel y luego comienzan a rastrear los subsistemas adyacentes en busca de suposiciones similares y medidas de seguridad faltantes. Y cada vez las encuentran más.
Ese patrón recurrente me preocupa más que cualquier número individual de CVE.
Inicié un clúster de ROSA y decidí probar Fragnesia directamente en OpenShift. El clúster ejecutaba OpenShift 4.21.15 en Red Hat Enterprise Linux (RHEL) CoreOS 9.6 con un kernel vulnerable 5.14.0-570.113.1.el9_6.x86_64. El subsistema vulnerable estaba presente. En teoría, el entorno debería haber sido explotable.
Lo que quería entender no era simplemente si el kernel era vulnerable. Ya lo sabíamos. Quería ver dónde se rompería realmente la cadena de explotación con diferentes configuraciones de seguridad.
Primero, implementé un pod completamente estándar con las protecciones predeterminadas de OpenShift. Nada sofisticado. Sin privilegios elevados. Sin SCC flexibles. Solo un contenedor Fedora vanilla que ejecuta sleep infinity.
La cadena de amenazas falló casi de inmediato.
OpenShift bloqueó la creación de espacios de nombres de usuario antes de que el ataque pudiera progresar de manera significativa. El subsistema vulnerable aún existía, pero el contenedor nunca adquirió las capacidades necesarias para alcanzar la ruta de código peligrosa en primer lugar. Las Restricciones del contexto de seguridad (SCC) predeterminadas de OpenShift, junto con la aplicación de SELinux, cerraron la puerta antes de que la amenaza comenzara a avanzar.
Esa parte no era sorprendente.
Lo que más me interesó fue el siguiente escenario, el tipo de configuración que muchas organizaciones utilizan en la realidad.
Creé una carga de trabajo con el SCC anyuid y ejecuté el contenedor explícitamente como ID de usuario (UID) 0. Esto es muy común en los entornos brownfield: entornos existentes donde las aplicaciones heredadas nunca se diseñaron bajo el concepto de privilegios mínimos y las organizaciones suelen ceder porque "la aplicación lo necesita".
Dentro del pod, tenía privilegios de root.
La cadena de amenazas siguió fallando.
Incluso con anyuid, SELinux continuó aplicando las restricciones de dominio container_t, lo que impidió las operaciones de espacio de nombres necesarias para continuar con la escalada. Esa es la parte que creo que la gente suele pasar por alto sobre el modelo de OpenShift: las capas de seguridad se superponen intencionalmente. Relajar un control no elimina automáticamente el resto de la barrera de seguridad.
En ese momento, decidí dejar de ser razonable.
Diseñé una configuración deliberadamente peligrosa con un SCC privilegiado, usuario root y seccomp sin restricciones. Esto es lo más permisivo que se puede configurar una carga de trabajo de OpenShift sin entregar el host directamente.
Y finalmente, las cosas empezaron a avanzar.
Los espacios de nombres de usuario funcionaron. unshare -U se ejecutó correctamente. La cadena de amenazas comenzó a progresar de una manera que los escenarios anteriores nunca permitieron. En muchas distribuciones de Kubernetes, aquí es donde la historia pasa de ser una "investigación de seguridad" a una "respuesta ante incidentes".
Pero la amenaza siguió fallando.
Fragnesia no solo requiere la creación de un espacio de nombres. Requiere una asignación correcta de UID/GID dentro del espacio de nombres para que el atacante pueda obtener las capacidades necesarias para acceder a las rutas de red vulnerables.
Se bloqueó ese último paso.
Incluso con SCC con privilegios, root y seccomp unconfined, SELinux continuó denegando las operaciones de escritura en /proc/self/uid_map. Sin una asignación de UID correcta, la cadena de escalada de privilegios falló. La falta de privilegios root en el espacio de nombres impidió el acceso a XFRM/ESP. Al no haber acceso al subsistema, se evitó la corrupción de la caché de páginas.
El kernel permaneció vulnerable en todo momento, pero el exploit falló. Esa distinción es fundamental.
Lo que las pruebas me reafirmaron es algo en lo que he creído durante mucho tiempo: una buena defensa en profundidad sigue siendo valiosa, especialmente cuando las cosas salen mal. No solo cuando todo está configurado a la perfección. No solo cuando todas las cargas de trabajo están intactas y cuentan con privilegios mínimos, y los equipos de seguridad obtienen todo lo que desean. Los entornos reales son caóticos. Se relajan los controles. Existen cargas de trabajo heredadas. Las concesiones operativas ocurren constantemente.
La pregunta es si la arquitectura todavía resiste tras producirse algunas de esas concesiones.
En este caso, así fue.
Incluso tras debilitar varias capas de seguridad simultáneamente, SELinux trató al contenedor como no confiable de forma fundamental. Esto impidió el paso final de escalada de privilegios necesario para completar la amenaza.
Esa es la diferencia entre las "características de seguridad" y una arquitectura de seguridad coherente. Esa conversación más amplia sobre la arquitectura me importa más que la propia CVE de Fragnesia. Porque si algo nos han enseñado las últimas semanas es que esta familia de vulnerabilidades probablemente no ha dejado de evolucionar.
La pregunta operativa que las organizaciones deben empezar a hacerse ya no es: "¿Hemos aplicado el parche para CVE-2026-46300?". La verdadera cuestión es: "¿Qué sucederá a nivel operativo cuando aparezca el CVE-2026-XXXXX el próximo martes y se dirija a otro subsistema que nadie vigilaba todavía?".
La amenaza evoluciona. Las señales, no.
Seamos realistas: a estas alturas, eso ya no parece algo hipotético.
Aquí es donde creo que Red Hat Advanced Cluster Security for Kubernetes adquiere mucho más valor que el simple enfoque basado en CVE. Lo interesante de Red Hat Advanced Cluster Security en este contexto no es que conozca Fragnesia específicamente. Se trata de que los patrones de comportamiento en estas cadenas de amenazas suelen reconocerse aunque cambie la vulnerabilidad exacta.
Resulta inusual que un contenedor de aplicaciones web cree espacios de nombres de usuario de repente. Que una carga de trabajo de aplicación ejecute /bin/su es inusual. Esas señales siguen siendo interesantes, sin importar si la amenaza se llama Copy Fail, Dirty Frag, Fragnesia, DirtyDecrypt o cualquier nombre que los investigadores inventen la próxima semana.
El CVE cambia, pero en estos casos, el comportamiento no lo hace.
Esto es importante porque los ciclos de divulgación avanzan más rápido de lo que muchas organizaciones pueden aplicar parches de manera realista en grandes flotas sin introducir inestabilidad operativa. La visibilidad de la arquitectura y el comportamiento te permite ganar tiempo. A veces, ese tiempo marca la diferencia entre ejecutar un plan de corrección controlado y pasar las siguientes 18 horas atrapado en un puente de incidentes, preguntándote qué clústeres están expuestos.
Lo mismo se aplica operativamente a escala de flota.
Es sencillo probar 3 pods en un laboratorio. La coordinación de los cambios de políticas en docenas o cientos de clústeres mientras las cargas de trabajo de producción permanecen en línea es un problema completamente diferente. Aquí es donde Red Hat Advanced Cluster Management for Kubernetes cambia la conversación de los esfuerzos reactivos a la implementación controlada. En lugar de auditar los clústeres de uno en uno, identificar configuraciones peligrosas y coordinar cambios en la postura de seguridad entre los equipos de forma manual, estableces una política consistente de forma centralizada y la propagas por todas partes.
Esa distinción adquiere una importancia fundamental cuando aparecen variantes nuevas cada pocos días.
En mi clúster de Red Hat OpenShift on AWS (ROSA), el kernel permaneció vulnerable durante las pruebas. Los subsistemas vulnerables permanecieron presentes. Técnicamente, los requisitos previos para la amenaza existían.
La cadena de explotación seguía rompiéndose porque los controles en capas interrumpían la escalada en varios puntos.
Luego, DirtyDecrypt comenzó a circular públicamente cuando aún estaba escribiendo este artículo.
La misma filosofía de explotación más amplia. Subsistema diferente. Las mismas defensas que ya se mantienen.
Eso no es suerte. Eso es arquitectura. Eso es defensa en profundidad.
Más información
Red Hat Product Security
Sobre el autor
Sean Rickerd, a distinguished professional in the technology and security domain, seamlessly blends his extensive career journey with a commitment to excellence. From his early days at SUSE to his current role as Principal Technical Marketing Manager at Red Hat, Sean's writing reflects a dedication to continuous learning. With a focus on authoring about cutting-edge fields like DevSecOps and Kubernetes security, he stands at the forefront of driving innovation and elevating security practices.
Más como éste
La nueva moneda de la velocidad empresarial
Las amenazas de la inteligencia artificial se mueven rápido. Tus defensas también deberían hacerlo.
Technically Speaking | Defining sovereign AI with open source
Technically Speaking | Inside open source AI strategy
Navegar por canal
Automatización
Las últimas novedades en la automatización de la TI para los equipos, la tecnología y los entornos
Inteligencia artificial
Descubra las actualizaciones en las plataformas que permiten a los clientes ejecutar cargas de trabajo de inteligecia artificial en cualquier lugar
Nube híbrida abierta
Vea como construimos un futuro flexible con la nube híbrida
Seguridad
Vea las últimas novedades sobre cómo reducimos los riesgos en entornos y tecnologías
Edge computing
Conozca las actualizaciones en las plataformas que simplifican las operaciones en el edge
Infraestructura
Vea las últimas novedades sobre la plataforma Linux empresarial líder en el mundo
Aplicaciones
Conozca nuestras soluciones para abordar los desafíos más complejos de las aplicaciones
Virtualización
El futuro de la virtualización empresarial para tus cargas de trabajo locales o en la nube
