Dos CVEs de page cache en dos semanas. Deadline de la CISA en 2 días. Y la mayoría de los clusters Kubernetes todavía corriendo kernels sin parche. En Tech86 seguimos esta situación de cerca porque confirma algo que repetimos desde hace tiempo: los contenedores no son límites de seguridad. El page cache compartido del kernel Linux es el eslabón débil que derriba esa premisa, y CopyFail y DirtyFrag son la prueba definitiva.
CopyFail: 4 bytes que comprometen un cluster
El CVE-2026-31431 explota un bug en el subsistema crypto del kernel Linux, específicamente en el algif_aead. El resultado: escritura de 4 bytes controlados en el page cache de cualquier archivo legible del sistema. El bug está presente desde 2017: casi una década de superficie de ataque expuesta.
Lo que hace CopyFail particularmente peligroso es la simplicidad del exploit. El PoC tiene 732 bytes en Python. Es determinístico: sin race condition, sin ventana de tiempo, sin necesidad de timing preciso. Funciona en Ubuntu, RHEL, Debian y Amazon Linux sin modificación alguna. En un cluster Kubernetes, el escenario es devastador: un pod sin privilegios corrompe el page cache de un binario compartido. El kube-proxy ejecuta ese binario corrompido durante la reconciliación. Diez segundos. Sin interacción humana. Cluster comprometido. Validamos esta cadena en EKS, GKE, AKS y Alibaba Cloud ACK: los cuatro principales proveedores administrados están vulnerables.
La CISA agregó CopyFail al Known Exploited Vulnerabilities (KEV) catalog con deadline del 15 de mayo. Cuando escribimos este artículo, faltaban 2 días. La mayoría de los clusters todavía no había aplicado el parche.
DirtyFrag: dos variantes, la misma clase
El CVE-2026-43284 y el CVE-2026-43500 forman DirtyFrag, dos variantes encadenadas que explotan los subsistemas ESP (esp4/esp6) y RxRPC del kernel. La misma clase de vulnerabilidad: primitiva de escritura en el page cache. Descubiertas por Hyunwoo Kim, tuvieron el parche upstream expuesto el 7 de mayo cuando un investigador externo construyó un n-day a partir de un commit público, con PoC público disponible en GitHub.
La comunidad integró los parches rápidamente: ESP el 7 de mayo, RxRPC el 10 de mayo. El kernel 6.20+ incluye ambos. Pero aquí está el problema real: la mayoría de los servidores en producción corre kernels de distribución, Ubuntu 6.17, RHEL 6.12, Amazon Linux 6.12. Estos kernels todavía no recibieron los parches por el canal de actualización convencional. El parche existe upstream, pero no llegó al node de su cluster.
Microsoft confirmó explotación in the wild. El GKE publicó el bulletin GCP-2026-030. El AKS desplegó hotfixes para ambas variantes. Esto ya no es un ejercicio teórico: los adversarios están usando estas vulnerabilidades activamente.
El problema estructural: el page cache es compartido
Dirty Pipe (2022). CopyFail (2026). DirtyFrag (2026). Tres vulnerabilidades, la misma clase, el mismo subsistema. Primitiva de escritura en el page cache. El patrón es claro, e ignorarlo es negligencia.
El page cache del kernel Linux es compartido entre todos los procesos del sistema. Los contenedores en el mismo node comparten ese cache vía overlayfs. No existe aislamiento de page cache entre contenedores. Cuando un proceso en un contenedor escribe en el page cache, esa escritura es visible para todos los demás contenedores en el mismo node. Así funciona el kernel por diseño.
Bruce Schneier y otros investigadores han discutido públicamente que en 2026 el concepto de "local" es engañoso. Todo contenedor, todo job de CI/CD, toda instancia WSL2, todo agente de IA con acceso a shell: todos comparten un kernel. Un LPE de page cache colapsa la frontera entre workloads. La premisa de que los contenedores aíslan aplicaciones es falsa. Aíslan namespaces, pero el kernel, y especialmente el page cache, es territorio compartido.
Por qué los parches no resuelven el problema
La respuesta estándar de la industria es "aplique el parche". Pero los parches son reactivos por naturaleza. Cada nueva primitiva de escritura en el page cache descubierta exige un nuevo parche, un nuevo ciclo de deploy, una nueva ventana de mantenimiento. Mientras tanto, los adversarios operan a la velocidad del PoC público.
El problema es más profundo. El kernel Linux no fue diseñado con aislamiento de page cache entre contenedores en mente. Cada subsistema que interactúa con el page cache, crypto, red, filesystem, es una potencial superficie de ataque. Los parches corrigen bugs individuales, pero no cambian la arquitectura fundamental. Mientras los contenedores compartan el mismo kernel y el mismo page cache, esta clase de vulnerabilidad va a seguir apareciendo.
En Tech86 vimos esta dinámica repetirse. Aplicamos parches de seguridad en nuestros clusters en horas, no días. Pero sabemos que el próximo Dirty Pipe, el próximo CopyFail, el próximo DirtyFrag está en camino. La corrección ya no son los parches. Es la arquitectura.
Defensa en profundidad: lo que realmente funciona
La protección contra exploits de page cache exige capas. La primera es Pod Security Standards en el perfil Restricted, con allowPrivilegeEscalation: false obligatorio. Esto no impide la corrupción del page cache, pero bloquea la escalada final: el momento en que el atacante convierte la corrupción de un archivo en ejecución de código con privilegios elevados.
La segunda capa es la reducción de superficie de ataque en el kernel. Módulos como esp4, esp6 y rxrpc deben bloquearse si no son necesarios. Menos subsistemas cargados, menos vectores de explotación. La tercera capa es aislamiento real del kernel: GKE Sandbox con gVisor o Kata Containers, que ejecutan cada pod en un kernel virtualizado separado. El propio GKE recomienda explícitamente no depender de los contenedores como límite de seguridad.
La cuarta capa es el monitoreo. Detectar corrupción de page cache es difícil, pero el comportamiento anómalo, como un pod intentando acceder a archivos de sistema fuera de su overlay, puede detectarse con seccomp customizado y herramientas de runtime security como Falco.
La arquitectura es la corrección
En Tech86 diseñamos Kubernetes con defensa en profundidad desde el inicio. Seccomp customizado por workload. Pod Security Standards Restricted como estándar, no como excepción. Nodes con kernels actualizados en horas, no semanas. Y para workloads que exigen aislamiento real, ofrecemos ambientes con kernel dedicado, porque sabemos que los contenedores solos no son suficientes.
Si su cluster Kubernetes todavía depende de la premisa de que los contenedores aíslan workloads, es hora de repensar la arquitectura. CopyFail y DirtyFrag mostraron que esa premisa no se sostiene. La próxima primitiva de escritura en el page cache está siendo descubierta ahora. La pregunta no es si va a aparecer, sino si su cluster va a estar preparado cuando llegue.
Conozca nuestra Cloud Administrada y entienda cómo operamos Kubernetes con las capas de seguridad que esta realidad exige.