O que se partiu, em termos simples
A 3 de julho de 2026, o investigador Jaeyoung Chung publicou o Bad Epoll, registado como CVE-2026-46242. É uma condição de corrida do tipo uso após libertação no subsistema epoll do núcleo Linux, a maquinaria padrão que um programa usa para vigiar muitos ficheiros e ligações de rede ao mesmo tempo. Os servidores, os serviços de rede e os navegadores web apoiam-se todos nele, razão pela qual não pode ser simplesmente desligado.
O efeito prático é categórico. Um atacante que já tenha qualquer ponto de apoio com poucos privilégios na máquina, uma shell de uma aplicação web comprometida, uma aplicação móvel maliciosa, uma conta de um prestador, pode escalar até root completo. A prova de conceito de Chung, submetida ao programa kernelCTF da Google, alarga uma janela temporal que normalmente mede apenas cerca de seis instruções de máquina e alcança root aproximadamente 99 por cento das vezes. O núcleo 6.4 e posteriores estão afetados salvo se já estiverem corrigidos; as compilações mais antigas baseadas em 6.1 não estão.
Porque só local não significa risco baixo
É tentador arquivar uma escalada de privilégios local na gaveta do mais tarde. Esse reflexo está errado para quem opera uma frota. As violações modernas têm dois passos. O primeiro passo, uma credencial exposta, uma sessão roubada, um front-end web vulnerável, leva um atacante até à máquina como utilizador limitado. O Bad Epoll é o segundo passo que converte esse utilizador limitado em root, desativa o registo e transforma um incidente contido num de todo o domínio.
O ângulo Android agudiza a questão. Uma aplicação maliciosa ou trojanizada que ultrapassa a baixa fasquia de ser instalada pode agora almejar root em dispositivos com núcleo 6.4 ou posteriores. Para qualquer organização que permita ao pessoal ler o correio da empresa em telefones pessoais, a fronteira que se presumia entre uma aplicação má e os seus dados acabou de ficar mais ténue. Isto é uma história de gestão de patches disfarçada de falha do núcleo.
O ponto cego da auditoria com IA que os operadores herdaram
Aqui está o detalhe que deveria chegar à sala do conselho, não apenas à equipa de segurança. O mesmo commit do núcleo de 2023 introduziu duas condições de corrida contíguas em cerca de 2.500 linhas de código epoll. O modelo Mythos da Anthropic apanhou a primeira, agora registada como CVE-2026-43074. Falhou a segunda, a que se tornou o Bad Epoll. As condições de corrida são notoriamente difíceis de detetar, e a revisão automática, tal como a humana, não as deteta de forma uniforme.
A lição não é que a revisão de código com IA falhou. É que uma passagem limpa da IA não é um certificado de desimpedimento. Se os seus responsáveis de engenharia começaram a citar auditorias automatizadas como prova de que o código é seguro, este é o estudo de caso que diz: um resultado positivo estreita o risco, não o fecha. Trate a revisão com IA como uma camada, financie o fuzzing e especialistas humanos ao lado dela, e nunca deixe que um relatório verde da máquina se torne a razão para saltar um controlo.
O que fazer esta semana
Aplique a correção de origem, o commit do núcleo a6dc643c6931, ou o backport da sua distribuição, dando prioridade aos anfitriões expostos à internet e multi-inquilino onde é mais provável que corra código local não fiável. Para os parques Android geridos, distribua as atualizações de segurança do fabricante e confirme que dispositivos correm no núcleo 6.4 ou posterior. O epoll não pode ser desativado, por isso não há atalho de configuração; o patch é a mitigação.
Depois use o momento como um teste de governança. Faça uma pergunta na sua próxima revisão de operações: se hoje uma conta com poucos privilégios for comprometida, o que a impede de se tornar root até sexta-feira? Se a resposta honesta depender de um patch que ainda não agendou, encontrou a brecha para a qual esta falha foi construída.
Leia a seguir: A sua defesa cibernética está preparada para ataques à velocidade da máquina? | Alibaba proíbe Claude Code por risco de porta dos fundos
