CVE-2026-46242 'Bad Epoll': exploit com 99% de confiabilidade transforma usuário comum em root no kernel Linux
Pesquisador da Universidade Nacional de Seoul publicou exploit funcional para CVE-2026-46242: qualquer processo local sem privilégios pode obter root em kernels Linux 6.4 a 6.12 e em dispositivos Android.
Jaeyoung Chung, doutorando do CompSec Lab da Universidade Nacional de Seoul, tornou público nesta sexta-feira (3 de julho) um exploit funcional para o CVE-2026-46242, batizado de "Bad Epoll". Qualquer processo local sem privilégios pode escalar para root. Kernels entre as versões 6.4 e 6.12.67 são afetados, cobrindo a geração mais recente de distribuições enterprise Linux e dispositivos Android em todo o mundo.
O que a falha faz e por que o raio de impacto é amplo
O CVE-2026-46242 é um use-after-free de race condition no subsistema epoll do kernel. O epoll coordena eventos de I/O em alta performance e está presente em praticamente todo servidor web, broker de mensageria e banco de dados Linux, o que coloca o código vulnerável em atividade contínua em quase toda infraestrutura Linux moderna.
A falha ocorre quando dois file descriptors epoll monitoram um ao outro e ambos são fechados quase ao mesmo tempo: o kernel libera a memória de um objeto enquanto ainda escreve nela pelo outro, corrompendo memória interna. A janela de race tem apenas seis instruções de largura. Chung encadeou quatro objetos epoll para amplificar a probabilidade de sucesso, atingindo 99% de confiabilidade no LTS 6.12.67 e 98% no COS 121-18867, a imagem base padrão das VMs do Google Cloud Compute Engine.
Bad Epoll pode ser acionado de dentro do sandbox do renderer do Chrome, perímetro que bloqueia a maioria dos bugs de kernel conhecidos. Dos 130 exploits já submetidos ao programa Google kernelCTF ao longo de sua história, aproximadamente dez são candidatos a rootear dispositivos Android, e CVE-2026-46242 está nesse grupo. O Google pagou a Chung o bounty base de US$ 71.337 pela descoberta.
Por que o patch levou cinco meses para chegar ao conhecimento público
A falha foi reportada em 17 de fevereiro de 2026. O commit de correção a6dc643c6931 chegou ao kernel upstream em 24 de abril, mas o embargo padrão do programa Google kernelCTF reteve a divulgação pública até esta semana. O código vulnerável foi introduzido no kernel 6.4 via commit 58c9b016e128, de abril de 2023; kernels do ramo 6.1-LTS não são afetados.
No mesmo subsistema, o CVE-2026-43074, race condition adjacente no mesmo código epoll, havia sido identificado por varredura automatizada com modelo de IA antes desta divulgação. Bad Epoll ficou fora da detecção. Segundo a análise técnica de Chung, depois de corrigido o primeiro bug, a falha adjacente deixou de acionar o sanitizer de memória do kernel, removendo o rastro de runtime do qual ferramentas de detecção automatizada dependem. O padrão é relevante para qualquer equipe que usa scanners baseados em IA para triagem de código: quando dois bugs coexistem no mesmo caminho de execução, corrigir um pode mascarar o outro de qualquer scanner que dependa de evidência de execução para sinalizar.
Exposição em infraestrutura global e o que fazer agora
Ubuntu 24.04 LTS, com kernel 6.8 padrão, e Debian 13 estão no intervalo afetado. O Google confirmou que instâncias COS 121 já recebem o kernel corrigido de forma automática. AWS e Azure não publicaram boletins individuais até o fechamento desta edição; equipes que mantêm kernels fixos em imagens customizadas precisam verificar se o commit a6dc643c6931 está incorporado antes de expandir capacidade.
Na Europa, o NIS2 obriga operadores de infraestrutura crítica a documentar vulnerabilidades com potencial de escalada de privilégios e a notificar autoridades competentes dentro de 72 horas após exploração confirmada. Nenhuma exploração in-the-wild foi relatada até o fechamento desta edição, mas um exploit com 99% de confiabilidade disponível publicamente elimina a barreira técnica para ataques oportunistas.
O vetor de maior risco em ambientes enterprise são nós host de clusters Kubernetes com namespaces de usuário não restritos, configuração presente por padrão em diversas distribuições gerenciadas de Kubernetes. Em pipelines de CI/CD compartilhados, qualquer job com código comprometido via supply chain pode usar Bad Epoll para escalar do isolamento de container para o host e acessar segredos de outros times. Centros de delivery na India, onde TCS, Infosys e Wipro operam Kubernetes multi-tenant para clientes na Europa, nos EUA e na Asia-Pacifico, têm superfície de ataque particularmente ampla. A atualização de kernel exige janela de manutenção, mas postergar a correção diante de um exploit público de alta confiabilidade prolonga desnecessariamente o risco.