Dois CVEs de page cache em duas semanas. Deadline da CISA em 2 dias. E a maioria dos clusters Kubernetes ainda rodando kernels sem patch. Na Tech86, acompanhamos essa situação de perto porque ela confirma algo que repetimos há tempo: containers não são boundaries de segurança. O page cache compartilhado do kernel Linux é o elo fraco que derruba essa premissa — e CopyFail e DirtyFrag são a prova definitiva.
CopyFail: 4 bytes que comprometem um cluster
O CVE-2026-31431 explora um bug no subsistema crypto do kernel Linux, especificamente no algif_aead. O resultado: escrita de 4 bytes controlados no page cache de qualquer arquivo legível no sistema. O bug está presente desde 2017 — quase uma década de superfície de ataque exposta.
O que torna CopyFail particularmente perigoso é a simplicidade do exploit. O PoC tem 732 bytes em Python. É determinístico: sem race condition, sem janela de tempo, sem necessidade de timing preciso. Funciona em Ubuntu, RHEL, Debian e Amazon Linux sem modificação alguma. Em um cluster Kubernetes, o cenário é devastador: um pod não privilegiado corrompe o page cache de um binário compartilhado. O kube-proxy executa esse binário corrompido durante a reconciliação. Dez segundos. Sem interação humana. Cluster comprometido. Validamos essa cadeia em EKS, GKE, AKS e Alibaba Cloud ACK — os quatro principais provedores gerenciados estão vulneráveis.
A CISA adicionou CopyFail ao Known Exploited Vulnerabilities (KEV) catalog com deadline de 15 de maio. Quando escrevemos este artigo, faltavam 2 dias. A maioria dos clusters ainda não havia aplicado o patch.
DirtyFrag: duas variantes, mesma classe
O CVE-2026-43284 e o CVE-2026-43500 formam DirtyFrag — duas variantes encadeadas que exploram os subsistemas ESP (esp4/esp6) e RxRPC do kernel. Mesma classe de vulnerabilidade: page cache write primitive. Descobertas por Hyunwoo Kim, tiveram o embargo quebrado em 7 de maio, com PoC público disponível no GitHub.
Os patches foram mergeados rapidamente: ESP em 7 de maio, RxRPC em 10 de maio. O kernel 7.0.6 inclui ambos. Mas aqui está o problema real: a maioria dos servidores em produção roda kernels de distribuição — Ubuntu 6.17, RHEL 6.12, Amazon Linux 6.12. Esses kernels ainda não receberam os patches pelo canal de atualização convencional. O patch existe upstream, mas não chegou ao node do seu cluster.
A Microsoft confirmou exploração no wild. O GKE publicou o bulletin GCP-2026-030. O AKS deployou hotfixes para ambas as variantes. Isso não é mais um exercício teórico — adversários estão usando essas vulnerabilidades ativamente.
O problema estrutural: page cache é compartilhado
Dirty Pipe (2022). CopyFail (2026). DirtyFrag (2026). Três vulnerabilidades, mesma classe, mesmo subsistema. Page cache write primitive. O padrão é claro — e ignorá-lo é negligência.
O page cache do kernel Linux é compartilhado entre todos os processos do sistema. Containers no mesmo node compartilham esse cache via overlayfs. Não existe isolamento de page cache entre containers. Quando um processo em um container escreve no page cache, essa escrita é visível para todos os outros containers no mesmo node. É assim que o kernel funciona por design.
Bruce Schneier publicou um texto sobre isso: em 2026, o conceito de "local" é enganoso. Todo container, todo job de CI/CD, toda instância WSL2, todo agente de IA com acesso a shell — todos compartilham um kernel. Um LPE de page cache colapsa a fronteira entre workloads. A premissa de que containers isolam aplicações é falsa. Eles isolam namespaces, mas o kernel — e especialmente o page cache — é território compartilhado.
Por que patches não resolvem o problema
A resposta padrão da indústria é "aplique o patch". Mas patches são reativos por natureza. Cada novo page cache write primitive descoberto exige um novo patch, um novo ciclo de deploy, uma nova janela de manutenção. Enquanto isso, os adversários operam na velocidade do PoC público.
O problema é mais profundo. O kernel Linux não foi projetado com isolamento de page cache entre containers em mente. Cada subsistema que interage com o page cache — crypto, rede, filesystem — é uma potencial superfície de ataque. Patches corrigem bugs individuais, mas não mudam a arquitetura fundamental. Enquanto containers compartilharem o mesmo kernel e o mesmo page cache, essa classe de vulnerabilidade vai continuar aparecendo.
Na Tech86, vimos essa dinâmica se repetir. Aplicamos patches de segurança em nossos clusters dentro de horas, não dias. Mas sabemos que o próximo Dirty Pipe, o próximo CopyFail, o próximo DirtyFrag está a caminho. A correção não é mais patches. É arquitetura.
Defesa em profundidade: o que realmente funciona
A proteção contra page cache exploits exige camadas. A primeira é Pod Security Standards no perfil Restricted, com allowPrivilegeEscalation: false obrigatório. Isso não impede a corrupção do page cache, mas bloqueia a escalada final — o momento em que o atacante transforma corrupção de arquivo em execução de código com privilégios elevados.
A segunda camada é redução de superfície de ataque no kernel. Módulos como esp4, esp6 e rxrpc devem ser bloqueados se não são necessários. Menos subsistemas carregados, menos vetores de exploração. A terceira camada é isolamento real do kernel: GKE Sandbox com gVisor, ou Kata Containers, que executam cada pod em um kernel virtualizado separado. O próprio GKE recomenda explicitamente não depender de containers como boundary de segurança.
A quarta camada é monitoramento. Detecção de corrupção de page cache é difícil, mas comportamento anômalo — como um pod tentando acessar arquivos de sistema fora do seu overlay — pode ser detectado com seccomp customizado e ferramentas de runtime security como Falco.
A arquitetura é a correção
Na Tech86, desenhamos Kubernetes com defesa em profundidade desde o início. Seccomp customizado por workload. Pod Security Standards Restricted como padrão, não como exceção. Nodes com kernels atualizados em horas, não semanas. E para workloads que exigem isolamento real, oferecemos ambientes com kernel dedicado — porque sabemos que containers sozinhos não são suficientes.
Se o seu cluster Kubernetes ainda depende da premissa de que containers isolam workloads, é hora de repensar a arquitetura. CopyFail e DirtyFrag mostraram que essa premissa não se sustenta. O próximo page cache write primitive está sendo descoberto agora. A questão não é se ele vai aparecer, mas se o seu cluster vai estar preparado quando ele chegar.
Conheça nossa Cloud Gerenciada e entenda como operamos Kubernetes com as camadas de segurança que essa realidade exige.