OpenAI usa agentes de IA para encontrar e corrigir 948 falhas críticas no kernel do Linux

A OpenAI publicou um relatório técnico detalhando um pipeline de agentes de inteligência artificial que caçou vulnerabilidades no kernel do Linux, o núcleo que roda por trás de servidores, nuvens, supercomputadores e boa parte dos celulares Android do planeta. O trabalho foi rodado em meados de outubro de 2026 sobre a versão mais recente do kernel e faz parte do programa Patch the Planet, iniciativa da OpenAI para achar e corrigir falhas em software de código aberto amplamente usado.

O resultado: 2.308 achados candidatos a vulnerabilidade, 1.724 confirmados de fato (74,7% do total) e 948 exploits distintos de escalonamento de privilégio local, o chamado LPE (local privilege escalation), quando um usuário comum do sistema consegue virar root, ou seja, dono completo da máquina, sem precisar de senha ou permissão especial. Para cada uma dessas 948 falhas, o próprio pipeline gerou um patch candidato para revisão humana, segundo o relatório da OpenAI.

Como funciona o pipeline, em cinco etapas

O sistema não é um único modelo rodando sozinho. É uma cadeia de agentes especializados, cada um com uma tarefa:

1. Descoberta: agentes "Scout" varrem o código do kernel e escolhem quais trechos valem auditoria, priorizando partes acessíveis a usuários com poucos privilégios.
2. Análise: agentes "Analyst" leem o código escolhido, entendem o modelo de ameaça e apontam candidatos a falha.
3. Validação dinâmica: outro agente tenta reproduzir cada candidato numa máquina virtual isolada, usando uma ferramenta de detecção de corrupção de memória chamada KASAN (Kernel Address Sanitizer).
4. Avaliação de explorabilidade: agentes "ExploitDev" tentam de fato explorar a falha validada, numa VM com as proteções padrão de uma distribuição Linux comum ligadas (SMEP, SMAP, KASLR, HARDENED_USERCOPY).
5. Geração de patch: o sistema propõe uma correção, que passa por revisão humana antes de ir para os mantenedores do kernel.

A OpenAI usou nesse pipeline um modelo de segurança cibernética ainda não lançado publicamente, descrito no relatório apenas como "upcoming cyber model". Em junho de 2026, a empresa já tinha mostrado uma versão anterior desse trabalho com o GPT‑5.5 Cyber, que gerou 24 exploits de LPE.

O que cada etapa custou em créditos de API

A OpenAI publicou o custo de cada estágio, pensando em dar a outros pesquisadores uma régua de quanto custa reproduzir o trabalho:

Somando as etapas, o custo total do ciclo de outubro de 2026 chegou a cerca de US$ 1,21 milhão, valor que bate com o informado pela própria OpenAI. Em julho de 2026, uma rodada anterior com uma versão diferente de modelo, chamada GPT‑5.6 Sol, tinha achado 166 exploits únicos por US$ 513.690, uma fração do resultado obtido três meses depois com o modelo mais novo.

A conta que interessa a quem defende

A OpenAI comparou o custo do pipeline com o valor que programas de recompensa por bugs pagariam pelas mesmas falhas. Usando os valores históricos do Pwn2Own (US$ 20 mil por exploit) e do TyphoonPWN (US$ 70 mil), os 948 exploits valeriam entre US$ 18,9 milhões e US$ 66,3 milhões, de 16 a 55 vezes o custo do pipeline.

Num teste separado contra o programa de recompensas kernelCTF do Google, que usa um kernel com proteções reforçadas, o pipeline achou 25 provas de vazamento de informação e 21 exploits de LPE por cerca de US$ 32.936 em 112 horas. Se aceitos pelo programa, esses achados renderiam cerca de US$ 1,5 milhão, 45 vezes o custo.

Com base nos valores públicos de pagamento, usando os modelos de ciber-segurança atuais, nosso pipeline de pesquisa de vulnerabilidades foi lucrativo na época desta pesquisa. Defensores deveriam analisar proativamente o próprio software para tornar caro demais para atacantes explorá-lo.

Based on public pay-out amounts, with current cyber-capable models, our vulnerability research pipeline was net profitable at the time of this research. Defenders should proactively analyze their software so that it becomes cost prohibitive for attackers to exploit.Equipe de Cibersegurança da OpenAI, relatório A thousand fewer paths to root

Lições de engenharia para quem constrói agentes

O relatório traz três achados que importam mais para quem monta pipelines de agentes do que para quem só lê a manchete.

O primeiro é um erro que passou despercebido até a revisão humana: em uma rodada inicial, o sistema reportou 200 exploits de LPE bem sucedidos, mas 20 deles tinham ganhado acesso root explorando uma falha diferente da que o agente foi mandado atacar. A OpenAI teve que adicionar uma checagem independente confirmando que o exploit final realmente usava a vulnerabilidade atribuída a ele. Para quem valida saída de agente automaticamente, o ponto é direto: verificar só o resultado final ("virou root?") não basta, é preciso verificar o caminho até lá.

O segundo é sobre orquestração. A OpenAI testou dar ao GPT‑5.5 Cyber uma lista de 103 técnicas de exploração de kernel em formato amigável ao modelo, o que subiu a taxa de sucesso de 76,2% para 88,9%. Quando repetiu o experimento com o GPT‑5.6 Cyber, o modelo mais novo já escolhia e aplicava as técnicas certas sozinho, sem o reforço externo, e ainda superou a versão anterior com todo o andaime.

Adicionar a mesma lista de técnicas ao modelo novo só rendeu 1,5 ponto percentual a mais. A conclusão da própria equipe é que vale reavaliar periodicamente se o orquestrador construído em cima de um modelo ainda compensa o custo de manutenção quando o modelo de base melhora.

O terceiro é sobre geração de patch. Nas primeiras tentativas, o modelo produzia correções que resolviam a falha mas traziam efeitos colaterais: código a mais do que o necessário, impacto em performance, quebra de convenção do projeto ou falha em cobrir variantes da mesma falha em outros pontos do código. Instruções mais detalhadas e iteração no processo melhoraram a qualidade, o que sugere que patch de segurança gerado por IA pode sim ficar correto e minimalista, mas não sai assim de primeira.

O ciclo de patch está mais rápido do que parece

Um dado que merece atenção de quem administra servidores Linux: dez dias depois do fim do escaneamento de outubro de 2026, 61 das falhas de LPE encontradas já tinham sido corrigidas oficialmente no kernel, outras 43 tinham patch em estágio de teste e 299 já estavam sendo discutidas publicamente pela comunidade. Isso quer dizer que, entre a descoberta e a correção pública, uma fatia relevante das falhas críticas muda de status em questão de dias, não de meses.

Para quem mantém infraestrutura em produção, isso reforça um ponto batido mas ainda negligenciado: manter o kernel atualizado deixou de ser detalhe de rotina de TI e virou janela de exposição mensurável. A própria OpenAI reconhece isso no relatório como desafio prático: ao reauditar o mesmo código depois de um tempo, é preciso revalidar contra a versão mais nova, porque parte das falhas já pode ter sido corrigida ou o código ao redor já mudou, sob risco de gerar relatórios duplicados ou obsoletos para os mantenedores.

O que ainda fica em aberto

A OpenAI não detalhou as dez técnicas de exploração que classificou como novas, alegando motivo de segurança, então não dá para saber tecnicamente o que torna esses exploits diferentes dos conhecidos até agora. Também não há, no material publicado, o nome definitivo do modelo usado no pipeline mais recente, só a descrição genérica de "modelo de cibersegurança ainda não lançado".

E o próprio relatório admite que os custos informados são um teto, não um piso: a OpenAI diz explicitamente que não otimizou o pipeline para custo, só para medir capacidade, o que significa que uma engenharia de produção mais enxuta tende a baratear bastante esse tipo de varredura automatizada, tanto para quem ataca quanto para quem defende.

Fonte: OpenAI News