Pesquisadores escapam da sandbox do Codex da OpenAI para executar comandos no host

Pesquisadores de segurança identificaram duas formas de sair da sandbox do Codex da OpenAI, permitindo a execução de comandos em uma máquina de desenvolvedor sem solicitação de aprovação e sem exibir nada na tela.

As falhas foram relatadas à OpenAI em 12 de agosto e corrigidas em oito dias, segundo Oren Yomtov da Accomplish AI.

A falha mais grave, chamada Heapjack, transforma uma ação rotineira em execução remota de código: abrir um repositório alheio no Codex, fazer uma pergunta sobre o código e conceder ao autor do repositório acesso não sandboxeado a comandos na máquina da vítima.

O Codex é o agente de codificação da OpenAI, disponibilizado como ferramenta de linha de comando e aplicativo de área de trabalho. Assim como os agentes concorrentes, ele executa as ações do modelo dentro de uma sandbox para impedir que código não confiável toque no sistema maior. Ambas as escapadas derrotam essa barreira a partir do interior.

A técnica Heapjack, descrita no relatório de Yomtov, foca em um componente chamado node_repl, que o Codex Desktop grava no arquivo global '~/.codex/config.toml' na instalação.

Não há opção de ativação nem configuração para desativá‑la, e como a entrada reside em um config compartilhado, usuários da linha de comando do Codex herdam a mesma ferramenta sem jamais ser perguntado.

O node_repl executa um único processo Node.js que mantém dois contextos de execução JavaScript separados. Um é confiável e contém o código da própria OpenAI; o outro é não confiável e executa o código do agente. O contexto confiável prova sua confiabilidade apresentando um token aleatório gerado a cada execução.

O problema é que ambos os contextos compartilham um único heap de memória, de modo que o token funciona apenas como uma string acessível à parte não confiável.

O código não confiável captura uma imagem do heap com 'v8.getHeapSnapshot()' e tenta todas as strings que se assemelham a um UUID. Um palpite incorreto devolve "não autorizado"; um token correto com argumento inválido gera um erro de validação real, confirmando ao atacante que o token está correto.

Com o token, o código não confiável escreve sua própria solicitação no mesmo pipe usado pelo contexto confiável para comunicar‑se com um processo pai não sandboxeado.

O processo pai verifica o token, reconhece que ele é válido e executa a tarefa. A demonstração de prova de conceito utilizou o comando do sistema 'open' para lançar uma aplicação fora da árvore de processos do Codex. Esse acesso alcança qualquer socket Unix, sendo o socket do daemon Docker o alvo mais óbvio, além de uma ferramenta para editar o arquivo de configuração global.

Tudo isso ocorre em modo de leitura apenas, o modo sandbox mais restritivo, onde o agente não deveria escrever nada.

A segunda falha, chamada Overpatch, está na ferramenta de linha de comando de código aberto do Codex. No modo workspace‑write, o agente só pode gravar dentro da pasta do projeto; um comando de shell que visa o diretório home é recusado.

Os pesquisadores conseguiram usar a própria ferramenta de patch do Codex, apply_patch, para escrever no diretório raiz do disco.

A ferramenta concede permissão de escrita à pasta pai de cada caminho especificado na patch. Ao nomear '/tmp', ela concede escrita ao nível superior do disco.

A exploração bem‑sucedida usa uma patch com duas alterações: uma que menciona '/tmp' apenas para ampliar a permissão e outra que anexa uma linha ao '.zshrc' por meio de um symlink no diretório home.

Sem a primeira alteração, a escrita seria recusada; com ela, o próximo terminal aberto pelo desenvolvedor executa a linha do atacante sem sandbox.

Ambas as falhas seguem um padrão semelhante: o mecanismo de enforcamento estava contido na própria ferramenta que deveria impor a restrição. O apply_patch determinou suas próprias permissões a partir de entradas fornecidas por um atacante; o node_repl manteve a separação entre código confiável e não confiável dentro do mesmo heap de memória.

Essa classe de falha não é nova. Em julho de 2026, pesquisadores da Pillar Security demonstraram um conceito semelhante em Cursor, Codex, Gemini CLI e no Antigravity do Google, onde um agente que permanece dentro da sandbox grava um arquivo que uma ferramenta confiável fora da sandbox executa posteriormente.

Um comentarista, ao reagir à postagem de Yomtov no X, afirmou que "contextos V8 isolam globals, não memória, então a sandbox era basicamente uma promessa que o heap nunca aceitou". Outro descreveu a fronteira de confiança como "um divisor de cômodos". O comportamento padrão, habilitado por padrão, despertou curiosidade, com questionamentos sobre por que um token privilegiado fosse acessível a partir de JavaScript não confiável.

A OpenAI corrigiu o Heapjack na versão 26.818.21641 do Codex Desktop e a Overpatch na versão 0.149.0 do Codex CLI, conforme relatado pela Accomplish.

Usuários devem atualizar para essas versões ou posteriores. Yomtov agradeceu à OpenAI por resolver ambas as questões em apenas oito dias após o relato.

A BleepingComputer entrou em contato com a OpenAI antes de publicar esta notícia.

Em declaração à BleepingComputer, um porta‑voz da OpenAI agradeceu aos pesquisadores:

"Agradecemos aos pesquisadores por nos contatar e compartilhar seus achados. Abordamos ambas as questões em agosto, mas continuamos a reforçar nossos sandboxes, com atualizações recentes que reforçam os controles sobre onde os agentes podem gravar arquivos e ampliam os testes dessas proteções em todas as plataformas."

Atualização, 21 de setembro, 05:29 h ET: Adicionada a declaração da OpenAI recebida após a publicação.

Construa sua estratégia de segurança para ataques impulsionados por IA

Participe do evento digital de duas horas com Mikko Hyppönen e líderes de segurança do NFL, CHANEL e Atlassian, explorando como os ataques de velocidade de IA mudam o cenário, quais práticas os defensores devem abandonar, e como validar, decidir, corrigir e revalidar em velocidade de máquina.