OpenAI usa agentes de IA para achar 948 falhas de escalonamento de privilégio no kernel Linux

A OpenAI publicou em novembro de 2026 os resultados de um pipeline autônomo que varreu o kernel Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps → em busca de vulnerabilidades de escalonamento de privilégio local (LPE, na sigla em inglês). O relatório, divulgado no post "A thousand fewer paths to root", descreve uma varredura feita em meados de outubro de 2026 que identificou 2.308 candidatos a vulnerabilidade, validou dinamicamente 1.724 delas e produziu 948 exploits funcionais capazes de dar a um usuário sem privilégios acesso root completo.

O trabalho é continuação do programa Patch the Planet, que em junho de 2026 já havia mostrado o modelo GPT-5.5 Cyber encontrando vulnerabilidades no kernel e desenvolvendo 24 exploits de prova de conceito. A diferença agora é escala: a OpenAI transformou aquele experimento pontual num pipeline de cinco estágios, rodando sobre um modelo de cibersegurança ainda não lançado publicamente, e conseguiu multiplicar o resultado por quase 40 vezes.

Como o pipeline funciona

O sistema é dividido em cinco etapas sequenciais, cada uma com agentes especializados:

• Descoberta: agentes "Scout" varrem o código em busca de alvos de auditoria relevantes (acessíveis por usuários sem privilégio), reduzindo o escopo antes de qualquer análise profunda.
• Validação dinâmica: agentes de triagem geram uma prova de conceito para cada candidato e tentam reproduzi-la numa VM isolada rodando kernel com KASAN (Kernel Address Sanitizer).
• Avaliação de exploitabilidade: agentes "ExploitDev" tentam converter a vulnerabilidade validada em exploit real, em VMs com proteções padrão de distribuição (SMEP, SMAP, KASLR, HARDENED_USERCOPY) ligadas.
• Geração de patch: o próprio pipeline propõe uma correção, seguindo convenções do código vizinho e checagem estática.
• Revisão humana: pesquisadores da OpenAI validam exploit, patch e severidade antes de reportar aos mantenedores do kernel.

O primeiro estágio auditou cerca de 2,8 milhões de linhas, só 7% da base total do kernel (que passa de 40 milhões de linhas), graças a uma triagem de reachability em vez de varrer tudo. Essa seleção é o que torna o custo viável: analisar código irrelevante para um atacante não privilegiado seria desperdício de tokens.

Os números de custo que importam para quem planeja orçamento

A OpenAI publicou o custo de cada etapa em créditos de API, e o detalhamento é a parte mais útil para quem pensa em programa de segurança com orçamento real:

O custo médio por exploit bem-sucedido ficou em US$ 359, mas tentativas fracassadas custaram em média US$ 3.922 cada (contra 1.169 sucessos a US$ 360) -- um sinal de que definir um critério de desistência (a OpenAI sugere parar após uma hora sem progresso) evitaria boa parte do desperdício.

Comparado a bug bounty, o pipeline deu lucro

A OpenAI também mediu o resultado contra valores reais de programas de recompensa. Usando os valores históricos pagos por Pwn2Own (US$ 20 mil) e TyphoonPWN (US$ 70 mil) por exploit de LPE em Linux, os 948 achados valeriam entre US$ 18,9 milhões e US$ 66,3 milhões, de 16 a 55 vezes o custo total do pipeline.

Num segundo teste, rodado contra o kernelCTF do Google (que usa um kernel hardened, com superfície de ataque reduzida), o pipeline achou 25 provas de conceito de vazamento de informação e 21 exploits de LPE em 112 horas, por US$ 32.936. Para efeito de comparação, apenas 26 exploits 0-day de LPE foram aceitos no kernelCTF em todo o ano de 2026 até a publicação do relatório. Se os 21 exploits fossem aceitos, a recompensa estimada chegaria a US$ 1,5 milhão, cerca de 45 vezes o custo.

Em resumo: com o modelo usado em outubro de 2026, encontrar e explorar vulnerabilidades do kernel via agentes de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → já é economicamente viável tanto para quem defende quanto, em tese, para quem ataca.

Os mantenedores do Linux reagiram rápido, mas isso também é um alerta

Um dado chama atenção para quem administra infraestrutura: dez dias depois do início da varredura de outubro, 61 das LPEs encontradas já tinham patch aplicado no upstream, 43 tinham patch em staging e 299 já estavam sendo discutidas publicamente. A velocidade de resposta da comunidade do kernel é um ponto positivo, mas reforça um risco operacional concreto: quem roda kernel desatualizado, fork customizado de embarcados ou distribuição sem cadência de patch rápida fica exposto por mais tempo à mesma classe de falha que a OpenAI está destampando em lote.

O relatório também documenta um erro interessante que vale como lição para quem for montar pipeline parecido: numa rodada inicial, 20 de 200 exploits reportados como bem-sucedidos na verdade tinham conseguido root explorando um 0-day diferente do que o agente deveria estar testando. A correção foi adicionar uma checagem independente confirmando que o exploit final usou exatamente a vulnerabilidade atribuída -- ou seja, validar resultado sem validar o caminho até ele é armadilha também em automação de segurança.

O que muda para quem roda Linux em produção

Nada disso está disponível como produto pronto: o modelo usado é descrito como "an upcoming cyber model", ainda não lançado, e o pipeline é um protótipo de pesquisa interno. O artefato mais próximo que um time de engenharia pode testar hoje é o Codex Security plugin, citado no próprio relatório como base do workflow dos agentes analistas, disponível no repositório openai/plugins no GitHub.

Ainda assim, a implicação prática para quem mantém servidores, clusters Kubernetes multi-tenant ou produtos que dependem de isolamento de kernel (containers compartilhando host) é direta: a barreira para encontrar vulnerabilidades de escape de privilégio no Linux caiu de forma mensurável, e isso corta nos dois sentidos. Times de segurança podem (e devem) considerar rodar varreduras automatizadas de reachability no próprio kernel usado em produção, especialmente em forks ou versões LTS mais antigas que não recebem a mesma atenção de pesquisadores que o master branch.

Também importa reler o achado sobre orquestração: a OpenAI notou que, conforme o modelo de base ficou mais capaz (de GPT-5.5 Cyber para GPT-5.6 Cyber), o scaffolding pesado de técnicas de exploração passou a agregar pouco (apenas 1,5 ponto percentual de ganho). Para quem avalia ferramentas de segurança baseadas em IA, isso sugere desconfiar de produtos vendidos com muita engenharia de prompt sobre modelos antigos: o ganho real tende a vir da capacidade do modelo, não da camada de orquestração em torno dele.

O que ainda fica em aberto

O relatório é explícito sobre não ter otimizado custo, só metodologia -- os valores publicados são um teto, não um piso. Também não há detalhe técnico completo sobre as 10 técnicas de exploração novas que os agentes teriam criado (duas de spray de objetos, duas de page grooming, cinco data-only e uma de confusão de tipo), retidas por razão de segurança. Isso deixa sem resposta pública a pergunta mais prática para o leitor técnico: quão replicável é esse resultado fora do ambiente controlado da OpenAI, com modelos hoje disponíveis via API comum em vez do modelo de ciber ainda não lançado.

Fonte: OpenAI News