948 formas de passar de uma conta comum ao controlo total
A OpenAI afirma que um sistema automatizado de investigação encontrou 948 vulnerabilidades distintas no kernel Linux que poderiam permitir a alguém com uma conta de utilizador comum assumir o controlo total de um computador. A campanha custou 1 213 430 dólares em créditos de API de IA e gerou patches candidatos para análise humana, segundo a divulgação dos resultados da empresa, a 4 de novembro de 2026.
Índice
- 948 formas de passar de uma conta comum ao controlo total
- Como os agentes analisaram milhões de linhas de código
- O que demonstraram os exploits funcionais
- Como se comparou a campanha de outubro com trabalhos anteriores
- Porque não bastava obter acesso root para validar uma descoberta
- O que compraram os 1,2 milhões de dólares e como a OpenAI avaliou o valor
- Dez técnicas alegadamente novas, sem divulgação dos detalhes
- A distância entre uma correção no projeto principal e um computador protegido
- Um ciclo de descoberta mais rápido vai além dos computadores Linux
- Pontos principais
Os resultados detalhados no relatório de investigação da OpenAI explicam como se chegou ao número: os agentes produziram 1 169 exploits funcionais de escalada de privilégios local e, em seguida, agruparam as descobertas relacionadas através da análise de variantes e desenvolveram 948 patches distintos. A OpenAI usa esse número final como a contagem de vulnerabilidades únicas.
Uma falha de escalada de privilégios local permite que uma pessoa ou um programa já em execução numa máquina obtenha poderes normalmente reservados ao administrador, conhecidos como root. O kernel Linux é o software central que gere a memória, o hardware e as permissões de acesso. Quebrar essa barreira pode transformar um acesso limitado no controlo do sistema.
A OpenAI testou os exploits numa distribuição Linux comum, cujo nome não revelou, com as proteções de segurança habituais ativadas. A empresa descreveu o modelo de IA que alimentava o processo como um modelo cibernético ainda por lançar, sem indicar uma data de lançamento nem identificar a distribuição. Os totais de descobertas, os custos e as alegações de novas técnicas de ataque são resultados comunicados pela própria OpenAI.
O desafio imediato é fazer chegar as correções aos computadores que as pessoas realmente utilizam. Durante a investigação, os colaboradores do Linux já estavam a corrigir ou a discutir centenas de descobertas sobrepostas. Os investigadores humanos ainda tiveram de verificar se cada exploit visava a falha alegada e se o patch proposto corrigia a causa.
Como os agentes analisaram milhões de linhas de código
A OpenAI começou por selecionar partes do Linux acessíveis a utilizadores comuns e relevantes para a segurança. Os agentes de reconhecimento identificaram 5 034 alvos de auditoria, abrangendo cerca de 2,8 milhões de linhas de código, aproximadamente 7% de uma base de código do kernel com mais de 40 milhões de linhas.
Em seguida, os agentes analistas examinaram esses alvos, estudando o funcionamento do código e onde um atacante poderia atravessar uma barreira de segurança. No espaço de 12 horas, produziram 2 308 descobertas candidatas, depois de eliminar duplicados. A seleção dos alvos custou 3 426 dólares em créditos de API; a sua análise custou 316 549 dólares.
O processo completo teve cinco fases: descoberta de vulnerabilidades, validação dinâmica, avaliação da explorabilidade, geração de patches e análise humana. Cada fase respondia a uma pergunta diferente, passando de código suspeito para um problema de segurança demonstrado e, depois, para uma proposta de correção.
Durante a validação, os agentes tentaram reproduzir cada caso candidato numa máquina virtual isolada, usando o Kernel Address Sanitizer, uma ferramenta que deteta certos erros de memória. Observaram os resultados dos programas e os registos do sistema, ajustando os programas de teste até desencadearem o problema ou esgotarem as tentativas permitidas.
Em 30 horas, o sistema reproduziu 1 724 vulnerabilidades, cerca de 74,7% dos casos candidatos. A OpenAI afirmou que muitas das restantes descobertas exigiam privilégios superiores ou dependiam de condições difíceis de desencadear dentro do tempo disponível. Atribuiu 3,1% das descobertas candidatas a análises incorretas que envolviam uma condição impossível. As 30 horas dizem respeito a esta fase de validação, enquanto a análise e o exame manual subsequentes se prolongaram por 10 dias.
O que demonstraram os exploits funcionais
O passo seguinte da OpenAI foi determinar quais dos erros reproduzidos poderiam expor informação ou permitir obter acesso root. Um agente de triagem reduziu as descobertas a 313 casos candidatos de fuga de informação e 1 238 possíveis casos de escalada de privilégios.
Os agentes de desenvolvimento de exploits produziram 291 provas de conceito de fuga de informação e 1 169 exploits funcionais de escalada de privilégios. Uma prova de conceito é um programa de teste que demonstra que uma vulnerabilidade pode ser desencadeada. Um exploit vai mais longe e usa a falha para obter uma consequência de segurança, como privilégios de administrador.
As máquinas de teste mantiveram ativadas proteções como a aleatorização de endereços, as restrições ao acesso do kernel à memória dos utilizadores e as verificações da cópia de dados. A aleatorização de endereços torna mais difícil para um atacante prever localizações úteis na memória. Manter estas proteções ativadas aproximou os testes de uma instalação normal de computador de secretária.
A OpenAI também testou uma versão adaptada do ambiente kernelCTF da Google, que tem uma superfície de ataque mais reduzida e proteções adicionais. Essa campanha produziu 25 provas de conceito de fuga de informação e 21 exploits de escalada de privilégios ao longo de 112 horas, com um custo de API de cerca de 32 936 dólares. A adaptação omitiu a mitigação SLAB_VIRTUAL, por ser incompatível com a versão mais recente do kernel usada no teste.
A OpenAI comunicou ter encontrado uma vulnerabilidade no QEMU TCG, parte da infraestrutura de virtualização utilizada nos testes kernelCTF. A descoberta levou a que o próprio ambiente de investigação fosse incluído na análise de segurança.
Como se comparou a campanha de outubro com trabalhos anteriores
A investigação da OpenAI sobre o Linux expandiu-se através de várias experiências em 2026. A empresa enquadrou o trabalho no Patch the Planet, a sua iniciativa para ajudar os responsáveis pela manutenção a descobrir e corrigir vulnerabilidades em software amplamente utilizado.
- Junho de 2026: a OpenAI divulgou 24 exploits de escalada de privilégios no Linux, desenvolvidos com o GPT-5.5 Cyber.
- Final de julho de 2026: uma campanha com o GPT-5.6 Sol encontrou e explorou 166 vulnerabilidades únicas de escalada de privilégios, com um custo de API de 513 690 dólares.
- Meados de outubro de 2026: o modelo cibernético mais recente produziu exploits para 948 vulnerabilidades distintas de escalada de privilégios, acompanhados de patches candidatos, a um custo de 1 213 430 dólares.
- 4 de novembro de 2026: a OpenAI publicou o relato do processo e dos resultados.
A campanha de outubro encontrou cerca de 5,7 vezes mais vulnerabilidades únicas de escalada de privilégios do que a campanha de julho, gastando aproximadamente 2,4 vezes mais. Calculando a partir destes totais, a despesa de API por descoberta única baixou de cerca de 3 095 para 1 280 dólares.
Ambas as campanhas examinaram a versão mais recente da branch master do kernel Linux disponível na altura. A OpenAI afirmou que o modelo de outubro encontrou substancialmente mais vulnerabilidades, apesar de terem decorrido mais três meses de correções e reforço da segurança do kernel. Defendeu que o software crítico deve voltar a ser analisado à medida que os modelos se tornam mais capazes.
Porque não bastava obter acesso root para validar uma descoberta
A OpenAI deparou-se com um problema básico numa experiência inicial: 20 de 200 exploits bem-sucedidos obtiveram acesso root através de uma vulnerabilidade diferente daquela que tinha sido atribuída ao agente. O ataque funcionou, mas a explicação sobre o erro que explorou estava errada.
Isso era importante para a aplicação de correções. Os investigadores precisam de relacionar o resultado observado com a causa correta, para que os responsáveis pela manutenção possam reparar o código responsável. A OpenAI acrescentou verificações independentes depois de descobrir as atribuições erradas.
Yash Kadakia, fundador e diretor de tecnologia da Security Brigade, explicou por que motivo as empresas precisam tanto de resultados reproduzíveis como de explicações corretas:
«Alcançar um resultado e explicar corretamente como o alcançou são duas coisas diferentes», afirmou.
Os pacotes finais da investigação da OpenAI incluíam uma análise da causa, um programa de teste mínimo que desencadeava uma falha, um patch candidato e um exploit completo. Investigadores humanos de segurança analisaram o exploit, a correção e a gravidade proposta antes de comunicarem as descobertas aos responsáveis pela manutenção.
O desenvolvimento dos patches também exigiu várias iterações. As correções iniciais geradas por IA introduziam por vezes alterações desnecessárias ou compromissos de desempenho, ou deixavam por resolver variantes relacionadas de uma vulnerabilidade. Testar diferentes variantes de um ataque ajudou os investigadores a avaliar se uma correção abrangia o problema mais amplo.
O que compraram os 1,2 milhões de dólares e como a OpenAI avaliou o valor
A OpenAI comunicou um custo total de campanha de 1 213 430 dólares, ou aproximadamente 1 279 dólares por descoberta única de escalada de privilégios. Estes valores referem-se às despesas de API dos modelos e do processo de trabalho, e não a uma contabilidade completa do trabalho de investigação e das despesas operacionais.
A avaliação da explorabilidade consumiu a maior parte do orçamento. A triagem custou 44 194 dólares, enquanto o desenvolvimento de exploits custou 775 929 dólares, incluindo 691 000 dólares para casos candidatos de escalada de privilégios e 84 929 dólares para casos candidatos de fuga de informação.
As falhas difíceis podiam ser particularmente dispendiosas. A OpenAI comunicou uma despesa média de cerca de 3 922 dólares por cada uma de 69 tentativas falhadas de escalada de privilégios, em comparação com cerca de 360 dólares por cada exploit bem-sucedido. Alguns casos difíceis envolviam condições de corrida, em que o sucesso depende de os acontecimentos ocorrerem numa ordem ou num momento precisos.
A OpenAI comparou as 948 descobertas com prémios históricos de competições: 20 000 dólares na Pwn2Own e 70 000 dólares na TyphoonPWN por exploits de escalada de privilégios no kernel Linux. Aplicando estes valores, obteve um valor hipotético entre 18,9 e 66,3 milhões de dólares, cerca de 16 a 55 vezes o custo de API da campanha.
A empresa estimou também que os seus 21 exploits kernelCTF poderiam render cerca de 1,5 milhões de dólares se fossem aceites pelo programa. Ambas as comparações são estimativas condicionais de prémios, estando os valores reais dependentes das regras dos programas e da aceitação das submissões. A OpenAI afirmou que o seu trabalho se centrou em medir as capacidades, e não em minimizar os custos, e que uma melhor otimização do processo poderia reduzir as despesas.
Dez técnicas alegadamente novas, sem divulgação dos detalhes
A OpenAI analisou uma amostra de 166 exploits e afirmou ter identificado pelo menos 10 técnicas de exploração novas para os seus investigadores e para os especialistas externos em exploração do kernel consultados durante o trabalho. Por razões de segurança, não divulgou instruções detalhadas.
As técnicas incluíam dois novos objetos usados para colocar dados controlados pelo atacante na memória do kernel, duas formas de organizar a memória para aumentar a fiabilidade, cinco métodos de obter privilégios através da alteração de dados e uma técnica que envolvia confusão de tipos arbitrária. A confusão de tipos ocorre quando o software trata um objeto como se fosse de outro tipo, podendo permitir o acesso a dados ou operações indevidos.
A OpenAI apresentou estes resultados como prova de que os agentes conseguiam desenvolver abordagens para além dos padrões de exploração conhecidos. A alegação baseia-se na análise da amostra feita pela empresa e na consulta de especialistas externos.
Para quem defende os sistemas, a consequência prática é que uma correção deve ser testada contra variantes relacionadas do ataque, além da primeira demonstração funcional. A OpenAI afirmou que um processo iterativo orientado por especialistas poderia ajudar a produzir patches que funcionassem corretamente, se integrassem no código existente e resistissem a ataques com variantes.
A distância entre uma correção no projeto principal e um computador protegido
Os responsáveis pela manutenção do Linux já estavam a agir enquanto decorria a campanha da OpenAI. No final dos 10 dias abrangidos pela análise e pelo exame manual, 61 descobertas de escalada de privilégios tinham sido corrigidas no projeto principal, 43 tinham patches em fase de integração e 299 estavam a ser comunicadas e discutidas publicamente.
Uma correção no projeto principal é uma alteração aceite no projeto central. Um patch em fase de integração ainda está a passar pelo processo de revisão ou integração. Depois, as distribuições Linux têm de disponibilizar atualizações adequadas aos seus clientes, que precisam de as instalar e ativar o kernel corrigido.
A OpenAI afirmou ter submetido centenas de relatórios e patches, começando pelas vulnerabilidades críticas, de acordo com as orientações da comunidade do kernel. Não apresentou uma discriminação completa das correções para as 948 descobertas.
Sakshi Grover, diretora de investigação da IDC, identificou como principal preocupação o período até as correções chegarem aos sistemas em produção:
«O risco não está tanto nas 948 vulnerabilidades, mas na duração do intervalo entre a descoberta e a chegada das correções aos sistemas em produção», afirmou.
Grover recomendou dar prioridade a máquinas utilizadas por vários clientes, sistemas automatizados de compilação de software, servidores de acesso partilhado, plataformas de contentores e máquinas de desenvolvimento. Incentivou também as organizações a pedir aos distribuidores Linux calendários para a inclusão das correções nas versões com suporte.
Thomas Di Giacomo, diretor de tecnologia e produto da SUSE, afirmou que a empresa utiliza ferramentas de IA semelhantes e trabalha com comunidades que mantêm projetos para coordenar a divulgação e a aplicação de patches. Descreveu a abordagem da SUSE como uma combinação de várias camadas de proteção e ambientes de execução de aplicações reforçados.
Um ciclo de descoberta mais rápido vai além dos computadores Linux
Os dados do Google Threat Intelligence Group indicam que foram divulgadas 10 740 vulnerabilidades em agosto de 2026, contra 5 045 em janeiro. No mesmo período, as divulgações classificadas como de alto risco aumentaram de 131 para 350, uma subida de cerca de 167%.
O Centro Nacional de Cibersegurança do Reino Unido abordou a descoberta de vulnerabilidades com recurso à IA numa avaliação publicada a 3 de novembro. A agência afirmou:
«A ampla disponibilidade de ferramentas de cibersegurança baseadas em IA conduziu quase certamente a um aumento significativo da descoberta de vulnerabilidades de dia zero», afirmou.
Uma vulnerabilidade de dia zero é uma falha para a qual os responsáveis pela defesa não tiveram oportunidade de preparar antecipadamente uma correção. O NCSC afirmou que as ferramentas defensivas de IA aceleraram a aplicação de patches, mas alertou que muitos sistemas continuavam expostos quando essas ferramentas não eram configuradas corretamente e implementadas de forma abrangente. As organizações teriam de adaptar os seus processos de aplicação de patches e de testes ao ritmo mais acelerado.
A abrangência do Linux torna este problema operacional vasto. O kernel é utilizado em dispositivos Android, infraestruturas na nuvem e supercomputadores. A infraestrutura de blockchain também está exposta: cerca de dois terços dos nós da Ethereum usam Linux, segundo dados do ethernodes.org citados na cobertura das descobertas.
Mudit Gupta, diretor de tecnologia da Polygon Labs, defendeu que a infraestrutura distribuída proporciona resiliência:
A descentralização traz diversidade e redundância à infraestrutura, tornando as criptomoedas muito mais resilientes a erros deste tipo do que o software tradicional.
O investigador de segurança Caducus também defendeu que a infraestrutura das criptomoedas se tornara mais resiliente após repetidas exposições a ataques. Para os operadores individuais, a tarefa concreta continua a ser manter as máquinas atualizadas e limitar os danos que uma conta comprometida pode causar.
A OpenAI recomendou defesas em camadas, incluindo ambientes isolados e sistemas de isolamento como o Firecracker e o gVisor. O aviso foi direto: um atacante com bons recursos e uma conta comum num sistema operativo sem as correções disponíveis poderá transformar esse acesso em controlo root. Descobrir erros mais depressa só ajuda se as correções chegarem rapidamente a esses sistemas.
Pontos principais
- A OpenAI comunicou 948 vulnerabilidades distintas de escalada de privilégios no Linux, após analisar 1 169 exploits funcionais e produzir patches candidatos.
- A campanha de outubro custou 1 213 430 dólares em créditos de API. A fase de validação reproduziu 1 724 vulnerabilidades candidatas em 30 horas.
- Os testes utilizaram uma distribuição Linux comum com as proteções habituais ativadas; o modelo e a distribuição não foram identificados.
- A análise humana continuou a ser necessária para verificar a causa de cada exploit e avaliar as correções propostas.
- Quando a análise terminou, os responsáveis pela manutenção já tinham corrigido 61 descobertas no projeto principal; havia 43 patches em fase de integração e 299 descobertas em discussão pública.
- A prioridade imediata para a defesa é disponibilizar e instalar as correções, sobretudo nos sistemas partilhados onde um acesso comum pode transformar-se em controlo de administrador.






