← Voltar para todas as publicações
Publicado em · por Renaud Deraison

Quarenta mil dólares por fuga

Em 6 de outubro, no Pwn2Own Ireland, a Ikotas Labs tirou o OpenAI Codex do seu sandbox com um único bug de injeção de argumentos e levou US$ 40.000. Agentes de código agora são uma categoria fixa do Pwn2Own: em Berlim, em maio, o Codex caiu três vezes e três equipes rodaram exploits contra o Claude Code. As regras dizem o que significa vencer: o agente abre o repositório, a página web ou o arquivo do competidor com o sandbox ligado, e código roda fora dele. No Bromure Agentic Coding, fora do sandbox do agente ainda é dentro de uma VM Linux que só guarda chaves substitutas, com suas saídas, seus diálogos de push e seu trace no Mac.

O Pwn2Own paga US$ 40.000 por código que roda fora do sandbox de um agente de código. Num notebook, fora do sandbox estão a sua conta, as suas chaves e os seus repositórios.

Às 18h de terça-feira, 6 de outubro, em Cork, a Ikotas Labs subiu ao palco do Pwn2Own Ireland 2026 com o OpenAI Codex como alvo. O registro de resultados da Zero Day Initiative tem uma linha: a Ikotas “used a single argument injection bug to exploit OpenAI Codex. They win $40,000 and 4 more Master of Pwn points.” O BleepingComputer e a Infosecurity Magazine noticiaram na manhã seguinte, entre os 32 zero-days do primeiro dia.

A ZDI só vai publicar o bug daqui a 90 dias, o prazo que o Pwn2Own dá aos fornecedores para lançar uma correção. As regras do concurso detalham o que o exploit precisava fazer.

O que significa vencer

Agentes de código têm categoria própria no Pwn2Own. As regras do Ireland 2026 listam dois alvos, Anthropic Claude Code e OpenAI Codex, a US$ 40.000 cada, ambos rodando no Windows 11. As condições são rígidas:

  • Os recursos de sandbox e isolamento ficam ativados na configuração padrão, e nenhum modo de execução inseguro (por exemplo, --dangerously-skip-permissions ou equivalente) fica ativo.
  • A tentativa “deve interagir com um recurso controlado pelo competidor (por exemplo, página web, repositório, arquivo de mídia)”, e o ataque “deve ser um caso de uso comum de um agente de código”.
  • Ela precisa obter execução de código arbitrário além dos “limites de sandbox e de permissões previstos” do agente, ou obter informações sensíveis “normalmente inacessíveis a partir do sandbox da aplicação”.

As regras definem três pontos de partida. O agente já está rodando numa pasta confiável e o ataque acontece dentro de uma sessão. Ou o agente é iniciado no repositório do competidor antes que alguém confie nele. Ou um aplicativo de desktop abre o projeto do competidor. São as três coisas que um desenvolvedor faz o dia todo: trabalhar, clonar algo novo, abrir algo novo.

As regras também deixam de fora uma lista de coisas que não contam: convencer o modelo a fazer, credenciais configuradas no ambiente, modos inseguros, servidores MCP de terceiros. O prêmio paga por uma só coisa: quebrar o limite do próprio agente.

Cinco meses, dois concursos

O Ireland é o segundo Pwn2Own com agentes de código na lista. Em Berlim, em maio, a Compass Security explorou o Codex no primeiro dia com “a single CWE-150 bug”, por US$ 40.000. A Doyensec o explorou no mesmo dia com um bug que o fornecedor já conhecia, e no terceiro dia Satoki Tsuji, da Ikotas Labs, explorou de novo por meio de uma vulnerabilidade de controle externo, abrindo calculadoras no alvo. O Security Affairs resumiu as três vitórias contra o Codex: “Each exploit used a different technique, meaning the attack surface is not a single narrow flaw but something broader.”

O Claude Code sofreu três exploits em Berlim, da Viettel Cyber Security, da Compass Security e da Out of Bounds. Os três foram colisões: os bugs funcionaram no palco, e a Anthropic já sabia deles. Uma colisão paga menos porque os pesquisadores não foram os primeiros, mas o exploit rodou do mesmo jeito contra a versão que o concurso instalou.

Aí veio o Ireland, cinco meses depois, e o Codex caiu de novo com um bug só.

A ZDI ainda não descreveu o bug do Ireland, mas injeção de argumentos é uma classe conhecida em agentes de código. A camada de permissões de um agente aprova um comando pelo nome: git, rg e find são somente leitura e rodam sem perguntar. O atacante fornece os argumentos, por meio de um nome de arquivo, um nome de branch ou um valor de configuração no repositório, e a ferramenta “somente leitura” recebe uma opção que executa um programa. O --upload-pack do Git, o --pre do ripgrep e o -exec do find aceitam um comando. Em julho, a Pillar Security relatou que a lista de comandos seguros do Codex confiava em git show pelo nome quando a chamada que ele fazia não era somente leitura.

Cada um desses exploits derrota uma verificação que vive dentro do agente, escrita pelo fornecedor do agente e distribuída com as atualizações dele. Os fornecedores corrigem cada um, e o concurso encontra o próximo, porque uma camada de permissões que analisa comandos de shell é um alvo grande, e um prêmio de US$ 40.000 mantém boas equipes procurando.

O que a fuga rende num notebook

O patrocinador do Pwn2Own decide quais “informações sensíveis” o exploit precisa obter, e os juízes conferem numa máquina de teste limpa. No notebook de um desenvolvedor, ninguém precisa escolher uma flag. Fora do sandbox do agente está a sua conta de usuário, e a sua conta guarda:

  • ~/.ssh/id_ed25519 e todos os hosts de known_hosts
  • ~/.aws/credentials, ~/.config/gcloud, ~/.kube/config
  • um token do gh com permissão de push, e arquivos .env em cada checkout
  • o próprio token OAuth do agente e o histórico de sessões
  • todos os outros repositórios do disco, e os perfis do navegador ao lado

O concurso também exclui caminhos que atacantes reais usam todo dia. Uma injeção de prompt que convence o agente a rodar um comando não conta. Nem um desenvolvedor que trabalha no modo --yolo para parar as perguntas. No mundo real, todos esses caminhos chegam ao mesmo lugar que uma fuga do sandbox: um processo rodando como você.

Num notebook: um só limite, e ele é do agenteVias de entradaRepo, página ou arquivo hostil+ um bug de sandbox (Pwn2Own)Injeção de promptfora das regras do concursoModo inseguro ou yolofora das regras do concursosandbox do agenteSua conta no notebook~/.ssh/id_ed25519~/.aws/credentials ~/.kube/configtoken gh com direito de push.env em cada checkouttoken OAuth, histórico agenteoutros repos, perfis webRede: qualquer host,qualquer porta, sem logTudo de que o exploit precisa já está aqui, e a saída também.
Num notebook, o sandbox do agente é a única linha. Uma fuga no estilo Pwn2Own, uma injeção de prompt ou um modo inseguro terminam no mesmo lugar: um processo com a conta, as chaves e a rede do desenvolvedor.

A mesma fuga numa máquina do Bromure

No Bromure Agentic Coding, o Codex e o Claude Code rodam dentro de uma VM Linux no seu Mac, uma VM por máquina. O sandbox do próprio agente continua lá e continua fazendo o seu trabalho. Abaixo dele fica um segundo limite que o fornecedor do agente não escreveu e que o repositório não consegue configurar: o Virtualization.framework da Apple, com o host do outro lado.

Repita o exploit da Ikotas Labs dentro de uma máquina. O agente abre o repositório do competidor, o argumento chega a um comando que não deveria tê-lo aceitado, e código roda fora do sandbox do Codex. Ele roda como o usuário da VM. Dali, procura cada item da lista do notebook e encontra a versão que a VM tem.

Os arquivos são os da máquina

A VM tem o próprio disco de sistema, um clone copy-on-write de uma imagem Ubuntu assinada, e o próprio diretório home. A home do seu Mac, as suas Chaves, os seus perfis do navegador e os seus outros projetos não estão nela. As únicas pastas do Mac que ela enxerga são as que você compartilhou com aquela máquina no painel Folders, e uma máquina para código não confiável não precisa de nenhuma: clone o repositório na home da VM.

As chaves são substitutas

Nenhum arquivo, variável de ambiente ou processo da VM contém uma chave de API real, um token OAuth, um segredo da AWS ou uma chave privada SSH. A VM guarda falsificações com o formato certo, como ANTHROPIC_API_KEY=sk-ant-api03-brm-… ou um token ghp_ que o GitHub rejeitaria. O proxy no Mac coloca o valor real depois que a requisição sai da VM, e só para o host a que a credencial pertence.

~/.ssh não tem chave privada para copiar. SSH_AUTH_SOCK é uma ponte via vsock para um ssh-agent no Mac, que assina quando pedido e nunca entrega a chave. Ative Ask before use para uma chave, e cada assinatura abre um diálogo no Mac.

As substitutas também funcionam como armadilhas. Quando o exploit empacota o que encontrou e manda para casa, o proxy vê um token falso indo para um host para o qual ele não foi emitido. Ele responde HTTP 451, não encaminha nada, pausa a VM e abre This environment may have been compromised no Mac, listando o token, o host a que ele pertence e o host para onde foi enviado.

A saída passa pelo Mac

Toda conexão que a VM abre passa pelo switch virtual e pelo proxy no host, seja qual for a porta ou o protocolo. O painel Guardrails da máquina tem um firewall de saída: regras por host, faixa de IP, protocolo e porta, e uma opção Unmatched traffic em Allow ou Deny. Uma máquina que você usa para código de estranhos pode liberar o provedor de modelos, os registros de pacotes e o GitHub, e negar o resto. A chamada do exploit para casa nunca chega a conectar.

A Security Timeline registra os veredictos do firewall, quer você tenha definido regras ou não. Ela está sempre ligada, para toda máquina, e uma conexão a um host de que o projeto nunca precisou aparece ali ao lado da sessão que a abriu.

Pushes e escritas esperam um clique

O pior prêmio da lista do notebook é o token do gh, porque permissão de push transforma uma máquina comprometida num pacote comprometido. Em máquinas novas, todo serviço protegido usa Prompt before write. Um git push via HTTPS é uma escrita, então o proxy o segura e o macOS mostra Allow write on "github.com" from workspace "…"? com a operação tal como passou pela rede. A mesma política cobre APIs de nuvem, Kubernetes, registros e bancos de dados. O diálogo é desenhado no Mac a partir do que o proxy leu, então o código na VM não consegue nem respondê-lo nem mudar o texto dele.

O trace guarda a história

Uma injeção de argumentos começa com uma chamada de ferramenta que parece rotineira. No nível de tracing padrão, AI request details, o proxy guarda cada troca com o provedor de modelos, criptografada no Mac, e o Trace Inspector decompõe cada uma em chamadas de ferramenta, comandos de shell e leituras de arquivo. Quando a ZDI publicar o bug em janeiro, você vai poder buscar nos seus traces o comando e o argumento que o dispararam, e o registro em que você busca foi escrito no Mac, fora do alcance de qualquer coisa que rodou na VM.

A limpeza abrange uma máquina

Se o exploit escreveu algo no diretório home, Rewind home… volta tudo ao checkpoint feito num boot anterior. Uma máquina marcada pelo detector de comprometimento se recusa a iniciar até você escolher Wipe and Launch, que reconstrói o disco e a home e mantém as suas configurações e as credenciais reais no Mac. Para código que você só quer olhar uma vez, bromure-cli vm run --rm inicia uma máquina que é apagada, disco e tudo, quando para.

No Bromure: a fuga cai numa VM, e as saídas ficam no MacVM da máquina (Ubuntu)Sandbox do Codex: rompido por um argumentoo código roda como usuário da VMO que ele encontraANTHROPIC_API_KEY=sk-ant-api03-brm-…GH_TOKEN=ghp_… (substituto)~/.ssh: sem chaves privadassó a home desta máquinasem home do Mac, sem outros projetosSwitch + proxy, no MacFirewall: host desconhecido → denyveredicto na Security TimelineSubstituto fora do escopo → 451, pausaTrace: cada chamada e comando,criptografado no MacDiálogo macOS: Allow write on …?POST /acme/app.git/git-receive-packInternetprovedor de IAregistros de pacotesgithub.comhost do atacante:nunca contatadoGuardado no Mac, fora da VMchaves de API e tokens OAuth · credenciais git e nuvem · chaves SSH · sua home · outros projetos · traces
A mesma fuga numa máquina do Bromure. O sandbox do agente continua quebrando, mas o código cai numa VM com a própria home, credenciais substitutas e nenhuma chave privada. As saídas, os diálogos de escrita e o trace ficam no Mac.

Seja qual for a porta que abriu

As regras do Pwn2Own excluem injeção de prompt, modos inseguros e credenciais armazenadas para que uma vitória meça uma só coisa: o limite do próprio agente. É o teste certo para um concurso. No seu notebook, os atacantes usam os três caminhos excluídos.

O limite da VM não depende de como o código saiu do agente. Um bug de injeção de argumentos, um README envenenado que convence o modelo a rodar um comando, um arquivo de teste que baixa um implante, um desenvolvedor que desligou as perguntas às 2 da manhã: cada um termina com código rodando como o usuário da VM, diante das mesmas substitutas, do mesmo firewall e dos mesmos diálogos no Mac. A OpenAI vai lançar a correção do bug do Ireland no próprio ritmo, e até lá o bug esbarra no limite da VM como os outros.

A fuga cai numa VM

Código que sai do sandbox do agente roda como o usuário da VM, com a home daquela máquina e as pastas que você compartilhou com ela. A home do seu Mac, as suas Chaves e os seus outros projetos não estão lá dentro.

As chaves são substitutas

Chaves de API, tokens git e segredos de nuvem reais ficam criptografados no Mac, e as chaves SSH assinam por uma ponte. Uma substituta enviada fora do escopo recebe um 451 e pausa a máquina.

Pushes exigem um clique no Mac

Com Prompt before write, o padrão em máquinas novas, um git push ou uma chamada destrutiva de nuvem espera um diálogo do macOS que a VM não consegue responder.

O registro fica no host

O firewall de saída, a Security Timeline e o trace rodam todos no Mac. Quando o bug for publicado, o histórico de cada sessão estará lá para consulta.

Conte com o próximo

O Pwn2Own volta na primavera, e os agentes de código estarão de novo na lista, porque um agente de código executa comandos na máquina de um desenvolvedor com o alcance desse desenvolvedor. Alguma equipe vai trazer um bug que ninguém viu. Os fornecedores vão corrigi-lo em até 90 dias, e o próximo concurso zera a contagem.

Continue atualizando os seus agentes, e rode-os numa máquina onde o prêmio atrás do sandbox do agente é uma VM com chaves substitutas. Para entender por que esse limite fica no host, leia O guarda e o shell discordaram e Onze testes passaram.