- Agentes baseados em Opus 4.5 e GPT-5.2 geraram mais de 40 exploits em 6 cenários usando uma vulnerabilidade zero-day do QuickJS
- O GPT-5.2 resolveu todas as tarefas, e o Opus 4.5 resolveu todas exceto duas, demonstrando capacidade autônoma de análise de código, depuração e composição de cadeias de exploit
- Os resultados do experimento sugerem que o desenvolvimento de exploits pode vir a ser limitado pela taxa de processamento de tokens, e não pelo número de hackers humanos
- A detecção de vulnerabilidades e a geração de exploits já chegaram a um estágio em que o desempenho aumenta proporcionalmente ao volume de tokens投入
- Destaca-se a necessidade futura de automatização de ataques cibernéticos e reformulação dos sistemas de avaliação de segurança
Visão geral do experimento
- Foi realizado um experimento de geração de exploits com Opus 4.5 e GPT-5.2 tendo como alvo uma vulnerabilidade zero-day no interpretador JavaScript QuickJS
- Foram aplicadas várias técnicas de mitigação de exploits (ASLR, NX, RELRO, CFI, shadow stack, seccomp etc.)
- Os agentes atingiram diversos objetivos, como obter shell, gravar arquivos e estabelecer conexão C2
- O GPT-5.2 resolveu todos os cenários, e o Opus 4.5 resolveu todas as tarefas exceto duas
- Cada execução tinha limite de até 30 milhões de tokens, com custo de cerca de 30 dólares
- Na tarefa mais difícil, a solução exigiu 50 milhões de tokens, cerca de 3 horas e 50 dólares
- Em um ambiente com sandbox seccomp e shadow stack ativados, o GPT-5.2 concluiu um exploit de gravação de arquivo com uma chamada de função em 7 etapas usando a cadeia de handlers de
exit da glibc
Limitações do experimento
- O QuickJS é muito menor e menos complexo do que um motor de navegador real, portanto há limites para generalizar os resultados
- Os exploits gerados não descobriram novas vulnerabilidades nas próprias técnicas de proteção, mas exploraram pontos frágeis já conhecidos na implantação
- A vulnerabilidade do QuickJS em si foi descoberta recentemente, e a forma como o GPT-5.2 a resolveu é avaliada como uma nova composição de cadeia que não havia sido documentada antes
A industrialização da intrusão
- “Industrialização” significa um estado em que a capacidade ofensiva de uma organização é determinada não pelo número de pessoas, mas pela taxa de processamento de tokens
- Para isso, são necessárias duas condições
- Agentes baseados em LLM devem conseguir explorar autonomamente o ambiente
- Deve existir um sistema de verificação preciso e rápido
- O desenvolvimento de exploits é um caso ideal que atende a essas condições
- É fácil montar o ambiente, e o procedimento de verificação é claro
- Ex.: no caso de um exploit para obter shell, a validação pode ser feita verificando o sucesso da conexão por meio de um port listener
- Em contrapartida, intrusão, elevação de privilégio, manutenção de acesso persistente e exfiltração de dados que exigem interação em tempo real são mais difíceis de industrializar
- Isso porque um comportamento incorreto em um ambiente real pode levar à detecção
Estágio atual
- A detecção de vulnerabilidades e o desenvolvimento de exploits já apresentam ganho de desempenho proporcional ao volume de tokens投入
- A mesma tendência também foi observada no projeto Aardvark da OpenAI
- No experimento, o limite era o orçamento, não a capacidade do modelo
- A automatização do hacking em redes reais ainda é incerta
- Segundo um relatório da Anthropic, houve um caso em que um grupo de hackers chinês tentou conduzir ataques usando API
- Porém, não há caso comercializado de agente de SRE (engenharia de confiabilidade de sites) totalmente automatizado
- Se a automação de SRE tiver sucesso, é muito provável que o hacking automatizado em redes adversárias também se torne viável
Conclusão e recomendações
- Este experimento muda a percepção sobre a extensão e o timing da automatização no domínio cibernético
- As formas atuais de avaliação de modelos (CTF, vulnerabilidades antigas, dados sintéticos) são inadequadas para medir capacidade real de ataque zero-day
- Laboratórios de fronteira e instituições de segurança em IA devem realizar avaliações com alvos zero-day reais (ex.: kernel Linux, Firefox)
- É necessário publicar relatórios no formato: “usamos X centenas de milhões de tokens para gerar Y exploits”
- Também são necessárias avaliações com equipamentos reais, como firmware de IoT
- Aponta-se a possibilidade de agentes baseados em Opus 4.5 ou GPT-5.2 gerarem exploits práticos em uma semana
- Recomenda-se a pesquisadores e engenheiros realizar experimentos diretamente e divulgar os resultados
- O código e os dados do experimento foram publicados em um repositório no GitHub
1 comentários
Comentários do Hacker News
Pediram ao GPT‑5.2 a tarefa mais difícil: descobrir como escrever uma string em um caminho específico do disco
Era um ambiente QuickJS com todas as proteções ativadas, como ASLR, memória não executável, full RELRO, CFI detalhado, shadow stack de hardware e sandbox com seccomp
O GPT‑5.2 resolveu o problema usando a cadeia de exit handlers da glibc com uma chamada de função em 7 etapas. Foi um resultado realmente impressionante
Na prática, a maioria dos exploits segue a ordem “encontrar a vulnerabilidade (difícil)” e depois “atravessar várias camadas de mitigação inútil (chato, mas possível)”
Mitigações probabilísticas funcionam contra ataques probabilísticos, mas o atacante encontra fraquezas de forma intencional
No futuro, provavelmente vamos nos arrepender de não ter migrado para WASM mais cedo
Até lá, vamos continuar empilhando mitigações de hardware enquanto tentamos conter os velhos problemas de overwrite de stack
Conheço bem isso por causa do meu trabalho, e a sensação de impotência só aumenta
Algo como vazar um ponteiro da libc com Use‑After‑Free
Em Rust seria bem mais difícil, mas se houver muitas chamadas à libc, é difícil ter defesa completa
O exploit do GPT‑5.2 não quebrou novas mitigações; ele explorou brechas de implementação já conhecidas
Hackers humanos fazem o mesmo: não “quebram” a mitigação em si
Ainda assim, no universo de CTFs, já está ficando mais comum ver LLMs resolvendo desafios de pwn de primeira
Esse avanço provavelmente vai derrubar implementações incompletas de mitigação e incentivar pesquisas em modelagem formal de exploits
Do ponto de vista de um pesquisador de segurança, a API de primitivas de leitura/escrita criada pela LLM é basicamente uma recombinação de APIs existentes
Não é tanto uma técnica nova, parece mais com um binário brinquedo de CTF
Ainda assim, os modelos mais recentes da OpenAI parecem relutar em gerar código real de exploit, então fico curioso se houve algum tipo de bypass de prompt
O autor levantou pontos interessantes, mas eu não estou muito preocupado
Ferramentas assim também podem ser usadas de forma simétrica pelos defensores
Dá para adicionar testes automáticos de segurança no CI, por exemplo rodando um “LLM Red Team”
O atacante só precisa acertar uma vez, enquanto o defensor precisa acertar sempre
Nos modelos atuais, a performance pass@x é 20~30% maior que maj@x
Mesmo assim, rodar um loop de Red vs Blue deve melhorar o nível de segurança
O atacante só precisa encontrar uma falha, enquanto o defensor precisa bloquear tudo
Ex.: o projeto Big Sleep do Google Project Zero
A lista de vulnerabilidades relacionadas pode ser vista aqui
O atacante pode transformar em arma um único bug, enquanto o defensor precisa encontrar todos os bugs
É a assimetria de “any vs all”
No fim, talvez só as empresas de LLM saiam realmente ganhando, vendendo tokens para os dois lados
É interessante que o Codex 5.2 tenha encontrado o exploit mais complexo
Eu também uso bastante o Opus 4.5, mas o modo Extra High thinking do Codex 5.2 é claramente forte
Não acredito nessa ideia de que o progresso das LLMs desacelerou. Na verdade, a impressão diminuiu porque as tarefas ficaram difíceis demais
Os logs podem ser vistos neste repositório
Cada um tem seu estilo
Não são divulgadas até perderem valor comercial
O QuickJS sempre foi um projeto meio brinquedo, com muitas vulnerabilidades sem patch
Seria mais interessante ver exploits em alvos de produção, como o curl
Convivem duas afirmações: que LLMs escrevem exploits excelentes e que geram relatórios de bug inúteis
Será que as duas podem ser verdade?
A qualidade da LLM varia conforme o prompt do usuário e a capacidade de interpretação
Quando um especialista usa isso de forma seletiva, dá para obter resultados excelentes
Relatórios gerados automaticamente acabam sendo um grande peso para mantenedores
Se você só disser “encontre vulnerabilidades neste programa”, vai receber muito absurdo,
mas se fornecer um loop de testes e um ambiente, o modelo melhora iterativamente e chega a resultados que realmente funcionam
Já relatórios de bug são ambíguos e difíceis de avaliar
Por exemplo, se em $100 houver um problema real de $50 misturado com 5000 relatórios falsos de $0.01,
fica muito mais difícil encontrar o diamante verdadeiro
A descrição do sandbox era vaga, então no começo pareceu suspeita
Olhando o repositório do autor, vi que o objetivo era “escrever a string ‘PWNED’ em /tmp/pwned”
Ou seja, não era escapar do sandbox, mas só uma restrição simples de escrita em arquivo
Até a criação da API de primitivas OOB R/W foi mais um caso de reaproveitar milhares de exemplos do GitHub
Achei marcante a frase de que “no futuro, a capacidade de hacking de um Estado ou organização será determinada não pelo número de hackers, mas pelo throughput de tokens”
A queda simultânea da barreira de entrada para fazer software e da barreira de entrada para hackear é uma combinação explosiva
Agora precisamos de novas plataformas com guardrails de segurança e verificabilidade
É arriscado demais depender de código feito por não especialistas