Um pesquisador de segurança publicou um exploit funcional e extremamente confiável para uma vulnerabilidade no kernel Linux que permite a um usuário comum, sem privilégios, obter controle total de uma máquina como root - sem senha, sem engenharia social, apenas com execução de código local. A falha, do tipo Local Privilege Escalation (LPE), catalogada como CVE-2026-46242 e apelidada de "Bad Epoll", afeta servidores e desktops Linux, além de smartphones Android com kernel 6.4 ou mais recente. Já existe uma correção no kernel principal, mas ela ainda não foi amplamente distribuída.
Como funciona o use-after-free do Bad Epoll
A falha está no epoll, o mecanismo que o kernel Linux usa para permitir que um único programa monitore milhares de arquivos abertos ou conexões de rede ao mesmo tempo - algo do qual praticamente todo servidor web, banco de dados e daemon de VPN depende. O pesquisador Jaeyoung Chung, do Computer Security Lab da Seoul National University, descobriu que, quando duas rotinas internas de limpeza do epoll, dentro da função ep_remove(), são executadas ao mesmo tempo, uma pode liberar um bloco de memória do kernel enquanto a outra ainda está escrevendo nele. Essa janela de use-after-free tem apenas cerca de seis instruções de CPU de largura, mas a prova de conceito de Chung, já pública no GitHub, aproveita a memória corrompida para construir uma cadeia de programação orientada a retorno (ROP) que sequestra o fluxo de execução do kernel e concede root ao invasor.
Quem está exposto
- Servidores e desktops Linux: qualquer distribuição rodando um kernel mainline a partir da versão 6.4 é vulnerável.
- Dispositivos Android: funcionamento confirmado em um Google Pixel 10 (kernel 6.6); dispositivos mais antigos ainda no ramo de suporte de longo prazo 6.1 não são afetados.
- O navegador como porta de entrada: como o exploit exige apenas execução de código local, pesquisadores observam que ele poderia, em teoria, ser lançado de dentro de um processo isolado como o renderizador do Chrome, transformando um simples bug de navegador em uma tomada completa do dispositivo.
A primeira tentativa de correção dos mantenedores do kernel, lançada após o reparo de uma falha relacionada anterior (CVE-2026-43074), não fechou totalmente a brecha - foram necessários mais cerca de dois meses até que uma correção adequada chegasse ao kernel principal. Esse processo de correção lento e em duas etapas explica exatamente por que tantos sistemas continuam expostos: distribuições e fabricantes Android costumam ficar vários ciclos de patches atrás do mainline, e servidores autogerenciados ficam ainda mais para trás.
Como verificar se você está exposto
Execute uname -r em um terminal para ver a versão do seu kernel. Se o resultado for 6.4 ou superior e sua distribuição ou dispositivo não recebeu uma atualização de segurança desde o início de julho de 2026, considere o sistema vulnerável e aplique o patch mais recente do kernel ou do fabricante o quanto antes.
Por que isso vai além dos computadores pessoais
O Bad Epoll não precisa de conexão de rede para funcionar - basta execução de código local, o que a princípio soa tranquilizador. Mas "local" hoje abrange um terreno enorme: servidores de hospedagem compartilhada, runners de CI/CD, instâncias VPS na nuvem, dispositivos de rede autogerenciados e qualquer máquina Linux que em algum momento execute código não confiável, seja um script baixado, um escape de contêiner ou uma aba de navegador comprometida. Assim que um invasor consegue qualquer ponto de apoio, por mais limitado que seja, o Bad Epoll o transforma em controle administrativo completo.
Um padrão mais amplo
O Bad Epoll também é um lembrete de o quanto a infraestrutura de rede moderna - incluindo as máquinas Linux que rodam gateways de VPN, proxies autogerenciados e roteadores domésticos - depende de um subsistema do kernel do qual a maioria dos usuários nunca ouviu falar. Uma única máquina sem correção em uma rede compartilhada, ou um provedor de VPN lento para implantar atualizações de kernel em sua frota de servidores, pode transformar um bug "puramente local" em uma exposição muito maior para todos que roteiam seu tráfego por ali. Esse caso dá continuidade a um tema recorrente neste ano: do roubo de credenciais da FortiGate ao Citrix Bleed, o elo mais fraco da infraestrutura de privacidade continua sendo código de kernel e firmware sem correção e de aparência banal, e não a criptografia em si.
