De um Upload num Fórum a um PR no Monorepo da OpenAI em 72 Horas. O Último Salto Foi o Agente.

“The entire timeline from initial discovery to access to OpenAI repo access took placê in less than 72 hours.” A frase está na divulgação da Hacktron sobre como três pesquisadores foram de um bug em um decodificador de imagem até um pull request dentro do monorepo interno da OpenAI. Leia a cadeia salto por salto: decodificador libheif, um pacote Debian sem o backport de segurança, ImageMagick, upload de imagem no Discourse, community.openai.com, uma falha de identidade no SSO da OpenAI, uma conta ChatGPT/Codex, a integração conectada ao GitHub, repositórios internos da OpenAI.

Cada salto, menos o último, é uma vulnerabilidade web comum. Um bug de decodificador, um pacote desatualizado, um fórum. O último salto é novo. Uma conta em um agente de código, com um conector GitHub acoplado, transformou o comprometimento de um fórum em uma escrita dentro de uma base de código privada. O agente foi o raio de explosão.

A cadeia, com relógio

A linha do tempo da invasão cabe inteira em 25 de julho de 2026, em UTC. Entre 05:00 e 06:00 os pesquisadores tinham execução remota de código e admin na instância do Discourse. Entre 08:00 e 10:00 registraram o relato pelo Bugcrowd. Entre 13:30 e 15:30 abriram um PR inofensivo de prova de conceito no monorepo interno, e os testes pararam por volta das 15:30. Às 22:49:45 a OpenAI confirmou a correção, cerca de 14 horas após o envio. A correção do Discourse ficou pronta em 27 de julho e o aviso, GHSA-vhm9-85gw-x335, saiu em 28 de julho. O link do PR interno foi ocultado a pedido da OpenAI, então a divulgação descreve o PR sem mostrá-lo.

A Hacktron é explícita sobre onde morava a escalada: “the vulnerability to escalate is not Discourse-specific. It is an OpenAI SSO issue that turned the fórum compromise into access to ChatGPT and Codex.” O fórum foi a entrada. A camada de identidade carregou o comprometimento para cima, e o conector do agente foi onde ele virou uma escrita.

Em 1 de setembro de 2026 a OpenAI pagou uma recompensa de US$ 6.500. Segundo a divulgação, a nota da OpenAI diz: “testing against the Discourse-hosted community.openai.com was explicitly excluded from our bug bounty program. The award recognizes the OpenAI-side finding.” São palavras da OpenAI citadas pela Hacktron. O fórum estava fora do escopo e a falha de identidade estava dentro, o que resume bem onde o problema real ficava.

A parte que escala

A cadeia contra a OpenAI foi uma instância de uma campanha mais ampla. A Hacktron escreve que a campanha “took two-months, cost less than $3,000 in tokens in total, and was conducted by three researchers. Adapting the exploit to each new company usually took only one or two days.” Sobre detecção: “We are not aware of any company that detected the activity except Shopify, even after thousands of images were sent and their image processors repeatedly crashed.”

Dois detalhes desse relato importam para quem orça uma defesa. O primeiro é o custo: menos de US$ 3.000 em tokens para uma campanha de dois meses contra várias empresas. O segundo é o salto de capacidade dentro da campanha. Segundo a Hacktron, o Opus 4.8 “struggled across several sessions” com ASLR, enquanto o Opus 5 teve sucesso horas depois do lançamento e produziu um exploit ARM64 funcional em 3 horas. O GPT-5.6 Sol resolveu o caso de alvo cego. O agente rodou em um loop autônomo /goal contra uma instância do Discourse Cloud colocada atrás de um proxy para parecer um CTF, porque o modelo recusava exploração remota. A recusa existia. Os pesquisadores contornaram mudando a aparência do alvo.

Ou seja, o custo de construir os saltos comuns caiu, e o salto que deu importância a todos eles foi uma conta de agente que não estava sendo tratada como credencial.

O mesmo formato, visto de dentro

A divulgação da Accomplish olha para o agente pela direção oposta. Onde a Hacktron alcançou o agente de fora e o usou como saída, Oren Yomtov começou dentro do sandbox do Codex e perguntou o que dava para fazê-lo executar. Duas fugas, ambas relatadas em 12 de agosto de 2026, ambas corrigidas em até oito dias, com patch em Codex Desktop 26.818.21641+ e Codex CLI 0.149.0+. (A Accomplish vende a mitigação que descreve, então a parte sobre como construiu esse produto é marketing. A linha do tempo e os números de versão estão na página.)

Overpatch é a primeira. No modo workspace-write do Codex CLI, segundo a página, o apply_patch “grants write access to the parent folder of each path in the patch”. Uma entrada de patch sob /tmp concede, portanto, escrita em /. Uma escrita em um .zshrc com symlink faz o próximo terminal aberto pelo usuário rodar sem sandbox.

Heapjack é a segunda, e a mais instrutiva. O Codex Desktop embute um servidor MCP de REPL Node, instalado em ~/.codex/config.toml. Código não confiável rodando ali tira um snapshot do heap do V8, faz força bruta no token por execução a partir do heap compartilhado, forja uma requisição pelo pipe de stdout compartilhado, e o processo pai nativo executa open fora do sandbox. Nas palavras da Accomplish: “All of it ran at read-only, the strictest sandbox mode… Codex never asked to approve anything.”

Modo somente leitura. Zero prompts. O diagnóstico da Accomplish serve para os dois bugs: “Both bugs have the same shape. The thing doing the enforcement was sitting inside the thing being enforced.” O token por execução vivia no mesmo heap que o código não confiável. A permissão do patch vinha dos próprios caminhos que o patch trazia.

Coloque as duas divulgações lado a lado e o quadro fica completo. De fora, uma conta de agente ligada ao SSO com um conector é um caminho de escrita para dentro dos seus repositórios. De dentro, a própria fiscalização do sandbox pode ser alcançada pelo código que ela fiscaliza. Um caso relacionado, de recurso autorizado usado como saída, está em Quando o Recurso Intencional do Sandbox de Agente Vira a Saída. O par de setembro acrescenta uma cadeia externa completa e um bypass do modo somente leitura corrigido em até oito dias.

Controle um: um token com escopo de um recurso

A autorização granular da Cloudflare para Workers é um modelo de permissão, e o post o descreve sem números de adoção. Trate-o como um desenho para copiar. O enquadramento do próprio post: “the last thing you want is for an agent to make a change in production, just because it was granted more access than it needs.”

Quatro papéis, três escopos. Os papéis formam uma escada:

Papel	O que pode fazer
Metadata Read-Only	Listas, configurações, observabilidade. Sem conteúdo.
Content Read-Only	Código e dados. Sem modificar.
Editor	Lê e escreve conteúdo e configurações. Sem criar ou apagar.
Admin	Controle total, incluindo apagar e conceder acesso.

Cada papel se aplica em um de três escopos: Developer Platform, Product ou Resource, onde Resource significa um único Worker. Tokens de API seguem o mesmo escopo, e o post diz que um token assim pode ser “given to your agent”.

Duas escolhas de desenho nesse modelo são a lição. Rotas e domínios customizados exigem uma permissão separada, “Workers Routes”, além de Editor, porque uma mudança de rota “could redirect production traffic or take the application offline”. Dados de Durable Object exigem Editor. E um 403 agora aponta para a permissão exata que falta, o que tira um motivo para pegar um token largo. Os papéis legados seguem sem depreciação, e, segundo o post, D1, R2 e KV vêm na sequência.

Aplique isso à cadeia da Hacktron. Uma conta de agente cujo conector GitHub tivesse o equivalente de Content Read-Only, com escopo de um repositório, teria transformado um PR no monorepo em uma leitura de um repositório. A falha de SSO continuaria sendo um achado sério. O raio de explosão seria uma fração do que foi.

Controle dois: credenciais fora do alcance do agente

O Agent Substrate do Google no GKE é a versão em runtime da mesma ideia. Do anúncio: “Hardware-isolated Cloud Hypervisor microVMs or gVisor sandboxes, paired with egress proxies that enforce granular network policies and inject credentials outside the reach of the agents themselves”. Os números de densidade e latência são do próprio Google: densidade 10x, retomada abaixo de 500ms, mais de 500 ativações de suspend/resume por segundo, mais de 1.000 agentes dormentes por host. O suporte GA para produção está disponível por allowlist.

A expressão que importa é “outside the reach of the agents themselves”. Heapjack funcionou porque o token estava no heap do agente. Overpatch funcionou porque a permissão de escrita vinha dos próprios caminhos que o patch trazia. Pela frase do próprio anúncio, uma credencial injetada pelo proxy de saída fica fora do alcance do agente: fora do heap dele, fora de um arquivo que ele lê. Faça o código do agente o que fizer, o segredo necessário para forjar uma requisição fica do outro lado de uma fronteira que o agente não construiu.

Essa é a regra que a Accomplish enunciou e o Google construiu: a fiscalização precisa viver fora daquilo que ela fiscaliza. A escada da Cloudflare aplica a regra ao que um token pode fazer. O Agent Substrate aplica ao lugar onde o token fica guardado. Já argumentamos, em Por Que Segurança de Agentes É um Problema de Arquitetura, que raio de explosão é uma propriedade arquitetural. Esses dois controles são essa propriedade na forma de configuração entregue. As primitivas de contenção anteriores estão em O Perímetro do Agente Ficou Específico.

Faça isso agora

Inventarie cada conta de agente de código no seu provedor de identidade e liste os conectores acoplados a cada uma. Trate cada conector como uma credencial com a união das permissões do dono da conta, porque foi assim que a cadeia da Hacktron o usou. Depois aplique os dois controles.

Primeiro, troque cada token de conector amplo por um com escopo de um único recurso, no degrau mais baixo que ainda permita ao agente fazer o trabalho. Use os quatro degraus da Cloudflare como modelo, rode Workers ou não: leitura de metadados, leitura de conteúdo, edição sem criar ou apagar, admin. Coloque operações que afetam produção, o equivalente a Workers Routes, atrás de uma concessão separada.

Segundo, tire as credenciais do alcance do agente. Se o token está em um arquivo de configuração que o processo do agente lê, ou no mesmo heap do código que o agente executa, assuma que a fiscalização pode ser alcançada por aquilo que ela fiscaliza. Um proxy que injeta a credencial é o formato de referência.

Terceiro, escreva quem revisa um PR aberto por uma conta de agente, porque nesta cadeia um PR inofensivo de prova de conceito foi aberto em um monorepo por uma delas. Um token vazado que continuou vivo é uma falha próxima, descrita em Histórico de Build Guarda a Própria Cópia do Seu Token, e o limite de autorização que ninguém definiu é o assunto de Seu Agente de Suporte Já Reseta 2FA.

Os saltos comuns continuarão comuns. Decodificadores de imagem terão bugs e distribuições perderão backports. O que você controla é se o último salto é uma leitura de um repositório ou uma escrita em todos.

Fontes

Hacktron AI (Harsh Jaiswal, Mohan Pedhapati, Rahul Maini). “Hacking OpenAI.” Setembro de 2026.
Accomplish (Oren Yomtov). “Escaping the OpenAI Codex sandbox, twice.” Setembro de 2026.
Cloudflare (Dina Kozlov). “Give every teammate and agent the right level of access to your Workers.” Setembro de 2026.
Google Cloud. “Agent Substrate available on GKE.” Setembro de 2026.

A Victorino ajuda times de engenharia a dar escopo aos conectores de agentes e tirar credenciais do alcance do agente antes que a próxima cadeia as encontre: contato@victorino.com.br | www.victorino.com.br