Principais destaques
- Duas falhas críticas: pesquisadores encontraram maneiras de escapar das restrições do Codex e executar comandos no sistema host.
- Um repositório podia bastar: o ataque Heapjack podia ser acionado quando o desenvolvedor simplesmente perguntava ao agente sobre um código malicioso.
- As correções já chegaram: a OpenAI corrigiu as vulnerabilidades em oito dias, mas os casos expõem um problema maior no isolamento de agentes de programação.
Um sandbox existe justamente para isso: deixar o agente brincar com código sem permitir que ele mexa no restante da máquina.
No Codex, pesquisadores descobriram duas maneiras de atravessar essa barreira.
As vulnerabilidades, batizadas de Heapjack e Overpatch, permitiam que código controlado por um atacante escapasse do ambiente isolado e chegasse ao sistema host. E uma delas podia transformar uma tarefa aparentemente inocente, como fazer uma pergunta sobre um repositório, em execução de comandos na máquina do desenvolvedor.
🔎 O detalhe mais incômodo: no caso mais grave, não era necessário um clique extra de aprovação nem uma mensagem evidente na tela.
O ataque começava onde ninguém espera 🚪
A falha Heapjack explorava um componente chamado node_repl, instalado por padrão pelo Codex Desktop em um arquivo de configuração global.
A ideia do componente era permitir a execução de código confiável da OpenAI e código não confiável produzido pelo agente em contextos JavaScript separados.
Em teoria, havia uma fronteira entre os dois.
Na prática, os dois contextos compartilhavam o mesmo heap de memória do V8, o mecanismo JavaScript usado pelo Node.js.
💻 O caminho do ataque: o código não confiável conseguia capturar um snapshot desse heap, localizar um token de autorização aleatório e reutilizá-lo para enviar requisições forjadas ao processo pai, que não estava submetido ao mesmo sandbox.
É aí que a coisa muda de escala.
Um desenvolvedor poderia abrir um repositório malicioso no Codex e simplesmente perguntar algo sobre o código. A interação aparentemente normal poderia fornecer ao atacante um caminho para executar comandos fora do ambiente isolado.
💡 O problema não era apenas o código malicioso. Era a possibilidade de transformar uma interação legítima com o agente em uma ponte para o sistema host.
E havia uma segunda porta aberta 🧩
A outra vulnerabilidade, chamada Overpatch, estava no Codex CLI de código aberto.
Nesse caso, o alvo era a ferramenta apply_patch, usada pelo agente para modificar arquivos.
No modo workspace-write, a expectativa era simples: o agente poderia alterar arquivos dentro da pasta do projeto, mas não deveria conseguir escrever arbitrariamente no restante do sistema.
Só que as permissões eram derivadas a partir dos próprios caminhos fornecidos pelo atacante.
📂 O desvio: ao incluir /tmp em um patch, o atacante conseguia ampliar o acesso de escrita para a raiz do disco.
A partir daí, um symlink podia ser usado para modificar o arquivo de configuração do shell do desenvolvedor.
O resultado apareceria depois.
Na próxima abertura de um terminal, o código inserido pelo atacante poderia ser executado fora do sandbox.
Uma comparação ajuda a entender
| Vulnerabilidade | Componente | Caminho explorado |
|---|---|---|
| Heapjack | node_repl | Token de autorização exposto no heap compartilhado |
| Overpatch | apply_patch | Permissões de escrita influenciadas por caminhos controlados pelo atacante |
O problema estava no lugar da barreira 🧱
Apesar de funcionarem de maneiras diferentes, os dois bugs apontavam para uma mesma questão de arquitetura.
O mecanismo responsável por aplicar a restrição estava dentro do próprio ambiente que precisava ser protegido.
No Heapjack, o segredo que separava os contextos de confiança ficava em uma área de memória acessível ao código não confiável.
No Overpatch, a própria ferramenta calculava suas permissões usando entradas que podiam ser manipuladas pelo atacante.
🗣 Em outras palavras: a porta tinha fechadura, mas parte da lógica da fechadura estava do lado de dentro.
Esse tipo de problema é especialmente relevante para agentes de programação. Diferentemente de um chatbot que apenas responde perguntas, esses sistemas podem ler arquivos, executar comandos e modificar projetos.
Quanto mais ferramentas recebem, maior também fica a superfície que precisa ser isolada.
Não foi só com o Codex ⚠️
O episódio também se encaixa em uma tendência mais ampla.
Em julho de 2026, pesquisadores da Pillar Security demonstraram escapes de sandbox semelhantes em outros agentes de programação, incluindo Cursor, Codex, Gemini CLI e o Antigravity, do Google.
Isso coloca as descobertas em um contexto maior: o isolamento deixou de ser apenas uma característica técnica de bastidores e passou a ser uma das principais fronteiras de segurança dos agentes capazes de operar computadores.
🔐 A diferença importante: um bug comum em uma ferramenta de desenvolvimento pode comprometer um projeto. Um escape de sandbox pode ampliar esse impacto para a própria máquina onde o agente está rodando.
Oito dias entre o alerta e a correção ⏱️
Os pesquisadores da Accomplish AI reportaram as duas vulnerabilidades à OpenAI em 12 de agosto de 2026, segundo Oren Yomtov.
A empresa corrigiu o Heapjack na versão 26.818.21641 do Codex Desktop e o Overpatch na versão 0.149.0 do Codex CLI.
Em declaração ao BleepingComputer, um porta-voz da OpenAI afirmou que a empresa está “continuamente fortalecendo nossos ambientes isolados, com atualizações recentes que restringem onde os agentes podem gravar arquivos e ampliam os testes dessas proteções em várias plataformas.”
Para quem trabalha com repositórios de terceiros ou código que não controla, a recomendação prática é direta: atualizar para as versões corrigidas.
O que isso muda para quem usa agentes de código? 🔎
O caso reforça uma diferença importante entre confiar no código que o agente está analisando e confiar no ambiente onde ele executa suas tarefas.
Um repositório pode conter código malicioso justamente para atacar a ferramenta que o analisa. Por isso, a fronteira de segurança precisa existir mesmo quando o usuário não está executando manualmente aquele código.
1️⃣ Atualizar o Codex: usar as versões corrigidas do Desktop e do CLI.
2️⃣ Desconfiar de repositórios externos: código de terceiros deve ser tratado como potencialmente não confiável, especialmente quando agentes têm acesso ao ambiente local.
3️⃣ Reduzir privilégios: quanto menos acesso o agente tiver ao sistema, menor tende a ser o impacto de um eventual escape.
4️⃣ Acompanhar correções de segurança: em agentes com capacidade de executar comandos ou modificar arquivos, atualizações não são apenas melhorias de produto.
E o sandbox, afinal, segura o quê? 🧠
Essa talvez seja a pergunta mais importante deixada pelos dois casos.
Sandboxes continuam sendo uma camada fundamental para limitar agentes de programação. Mas a segurança não depende apenas de colocar o agente dentro de uma “caixa”. Depende de garantir que o mecanismo que constrói essa caixa também esteja fora do alcance do código que ela deveria conter.
O Heapjack explorou memória compartilhada. O Overpatch explorou a lógica de permissões. Caminhos diferentes, mesma direção: encontrar uma parte da infraestrutura que acreditava estar aplicando a fronteira e fazê-la trabalhar contra ela.
A promessa do sandbox é permitir que um agente mexa no projeto sem transformar o computador inteiro em parte do projeto.
Depois dessas falhas, a pergunta que fica é simples: quantas outras ferramentas de agentes ainda estão usando a própria caixa para construir a fechadura?
