Pesquisadores de segurança encontraram duas formas de escapar do sandbox do OpenAI Codex, e uma delas permitia executar comandos na máquina de um desenvolvedor a partir do modo mais restritivo do Codex, sem pedir aprovação e sem exibir qualquer coisa na tela.
As duas falhas foram reportadas à OpenAI em 12 de agosto e corrigidas em até oito dias, segundo Oren Yomtov, da Accomplish AI.
A mais grave delas, chamada pelos pesquisadores de Heapjack, transforma uma ação rotineira em execução remota de código: ao abrir o repositório de outra pessoa no Codex e fazer uma pergunta sobre o código, quem escreveu aquele repositório pode acabar conseguindo executar comandos fora do sandbox no computador do desenvolvedor.
O Codex é o agente de programação da OpenAI, disponível como ferramenta de linha de comando e como aplicativo para desktop. Assim como agentes concorrentes, ele executa as ações do modelo dentro de um sandbox para impedir que código não confiável acesse o sistema mais amplo. As duas técnicas de escape funcionam justamente ao quebrar essa barreira por dentro.
A técnica Heapjack, descrita no relatório de Yomtov, mira um componente chamado node_repl, que o Codex Desktop grava no arquivo global `~/.codex/config.toml` durante a instalação.
Não há opção para desativá-lo nem configuração para impedir esse comportamento. Como a entrada fica no arquivo de configuração compartilhado, usuários do Codex CLI herdam a mesma ferramenta sem nunca serem consultados.
O node_repl executa um único processo Node.js que mantém dois contextos separados de execução JavaScript. Um é confiável e contém o próprio código da OpenAI. O outro é não confiável e executa o código do agente. O contexto confiável prova que é legítimo apresentando um token aleatório gerado do zero a cada execução.
O problema é que os dois contextos vivem no mesmo processo Node e compartilham o mesmo heap de memória, então o token acaba sendo apenas uma string armazenada em memória que o lado não confiável consegue ler.
O código não confiável tira uma cópia do heap com `v8.getHeapSnapshot()` e testa todas as strings com formato de UUID. Um palpite errado retorna “not authorized”. Um token correto, mas com argumento inválido, gera um erro de validação real, o que mostra ao atacante que o token está correto.
Com o token em mãos, o código não confiável escreve sua própria solicitação no mesmo pipe que o contexto confiável usa para falar com um processo pai nativo, fora do sandbox.
O processo pai verifica o token, vê que ele é válido e executa a tarefa. Na prova de conceito, foi usado o comando do sistema `open` para iniciar um aplicativo fora da árvore de processos do Codex. O mesmo acesso também alcança qualquer socket Unix, incluindo um socket do daemon Docker, além de uma ferramenta para editar o arquivo de configuração global.
Tudo isso acontece no modo read-only, o mais restritivo do sandbox, no qual o agente não deveria escrever nada.
A segunda falha, chamada Overpatch, está no Codex CLI de código aberto. No modo workspace-write, o agente só pode gravar dentro da pasta do projeto, e um comando de shell direcionado ao diretório pessoal é recusado.
Os pesquisadores conseguiram fazer a própria ferramenta de patch do Codex, `apply_patch`, escrever ali mesmo assim.
A ferramenta concede permissão de escrita ao diretório pai de cada caminho citado em um patch. Se o caminho for `/tmp`, ela passa a permitir gravação até a raiz do disco.
O exploit funcional usa um patch com duas alterações: uma que nomeia `/tmp` e não faz nada útil além de ampliar a permissão, e outra que adiciona uma linha ao arquivo `.zshrc` por meio de um symlink apontando para o diretório pessoal.
Se a primeira alteração for removida, a escrita é recusada. Com ela presente, o próximo terminal que o desenvolvedor abrir executa a linha do atacante fora do sandbox.
As duas falhas têm a mesma raiz: o mecanismo de proteção estava dentro da própria coisa que deveria controlar. O `apply_patch` calculava suas permissões com base em entrada fornecida pelo atacante. O node_repl mantinha o segredo que separava o código confiável do não confiável na mesma memória acessível ao código não confiável.
Em ambos os casos, o sandbox foi instruído, de dentro, a deixar algo passar.
Esse tipo de bug não é novo. Em julho de 2026, pesquisadores da Pillar Security demonstraram a mesma ideia em Cursor, Codex, Gemini CLI e no Antigravity do Google, em um cenário no qual um agente permanece dentro do sandbox, grava um arquivo e uma ferramenta confiável fora dele acaba executando esse arquivo depois.
Em reação à publicação de Yomtov no X, um comentário observou que “contextos V8 isolam globais, não memória, então o sandbox era na verdade uma promessa com a qual o heap nunca concordou”. Outro descreveu a barreira de confiança como “uma divisória de quarto”. O comportamento habilitado por padrão também recebeu críticas, com uma pessoa perguntando por que um token privilegiado podia ser acessado por JavaScript não confiável.
A OpenAI corrigiu o Heapjack na versão 26.818.21641 do Codex Desktop e o Overpatch na versão 0.149.0 do Codex CLI, segundo a Accomplish.
Os usuários devem atualizar para essas versões ou posteriores. Yomtov atribuiu à OpenAI a solução das duas falhas em até oito dias após seu relatório.
Publicidade
Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Guardsi: qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...