A segurança do OpenAI Codex entrou no radar de pesquisadores após a descoberta de duas vulnerabilidades capazes de romper o isolamento utilizado pelo agente de programação. Batizadas de Heapjack e Overpatch, as falhas foram encontradas pela equipe da Accomplish AI e demonstraram que um projeto malicioso poderia explorar componentes do Codex para ultrapassar as barreiras do sandbox.
O problema merece atenção porque agentes de programação baseados em inteligência artificial deixaram de ser apenas ferramentas de sugestão de código. Eles podem executar comandos, modificar arquivos, acessar repositórios e interagir com recursos disponíveis no computador do desenvolvedor. Nesse cenário, uma falha no isolamento pode transformar código não confiável em uma porta de entrada para o sistema hospedeiro.
As duas vulnerabilidades exploram mecanismos diferentes. Heapjack atinge o componente JavaScript node_repl instalado pelo Codex Desktop, enquanto Overpatch afeta a ferramenta apply_patch do Codex CLI. A Accomplish AI informou que comunicou as falhas à OpenAI em 12 de agosto de 2026, e ambas foram corrigidas posteriormente.
Como a falha Heapjack compromete a segurança do OpenAI Codex
O Heapjack explora a forma como o Codex Desktop utiliza o componente node_repl. Conforme a investigação, o aplicativo adiciona uma configuração [mcp_servers.node_repl] ao arquivo global ~/.codex/config.toml. Isso faz com que o componente também fique disponível para o ambiente do CLI.
O node_repl é implementado em Rust e possui funções que precisam operar fora das restrições aplicadas ao código JavaScript executado pelo agente. Entre essas capacidades estão a abertura de aplicativos, a comunicação com sockets Unix e a alteração de arquivos de configuração.
Para executar JavaScript com restrições, o componente inicia um processo Node.js dentro do sandbox. A arquitetura utilizava dois contextos vm do V8 nesse mesmo processo: um contexto confiável, responsável pelo código do Codex, e outro considerado não confiável, destinado ao código controlado pelo agente.
A intenção era razoável: permitir que o código não confiável executasse tarefas dentro de limites específicos sem obter acesso aos recursos privilegiados do contexto confiável.
O problema estava na separação entre esses contextos.
O problema de memória compartilhada no V8
Os dois contextos JavaScript estavam dentro do mesmo processo Node.js e compartilhavam o mesmo heap do V8. Isso significa que a separação lógica entre os contextos não equivalia a uma separação física completa da memória utilizada pelo processo.
O contexto confiável utilizava um token aleatório, gerado a cada execução, para demonstrar ao processo pai que uma solicitação vinha da parte autorizada do sistema. Esse token permanecia como uma string no heap compartilhado.
É nesse ponto que entra a API v8.getHeapSnapshot(), disponibilizada pelo Node.js para capturar informações sobre objetos existentes no heap. Segundo os pesquisadores, o código não confiável conseguia utilizar o snapshot para procurar o token armazenado na memória.
Em outras palavras, o segredo usado para separar o código confiável do não confiável estava armazenado em uma área que o segundo contexto conseguia examinar.
Isso representa uma falha importante de segregação de heap. A proteção não foi quebrada por adivinhação do segredo, mas porque a arquitetura permitia que o código considerado não confiável observasse a memória onde o segredo estava presente.
Do token roubado à execução fora do sandbox
A obtenção do token mudava completamente o cenário. O código não confiável poderia produzir solicitações que pareciam ter sido originadas pelo contexto confiável e enviá-las ao processo pai.
Esse processo pai aceitava o token como prova de autenticidade e disponibilizava operações que não estavam liberadas diretamente ao código isolado. A cadeia permitia, segundo a demonstração da Accomplish AI, chegar à execução de comandos sem as restrições do sandbox.
Um aspecto particularmente relevante é que a demonstração funcionava no modo read-only, descrito pelos pesquisadores como o nível mais restritivo do Codex. Nesse cenário, o agente não deveria conseguir modificar arquivos e não deveria ter acesso direto aos recursos necessários para executar comandos fora do ambiente isolado.
A pesquisa afirma que um repositório malicioso poderia explorar essa cadeia quando fosse aberto pelo Codex. Assim, o código presente no projeto poderia obter o mesmo nível de acesso ao sistema que teria caso o sandbox tivesse sido desativado.
Para desenvolvedores que trabalham com repositórios externos, isso muda a forma de avaliar a segurança de agentes de IA: um projeto aparentemente destinado apenas à análise pode conter instruções ou código capazes de explorar a própria ferramenta utilizada para examiná-lo.
O que o Overpatch revela sobre a segurança do Codex CLI
O Overpatch segue uma abordagem diferente. A vulnerabilidade está na ferramenta apply_patch, utilizada pelo Codex CLI para modificar arquivos do projeto.
No modo workspace-write, o objetivo é restringir as operações de escrita ao diretório do workspace. Dessa forma, o agente pode editar o projeto sem receber automaticamente permissão para alterar qualquer arquivo existente no computador.
O problema descoberto pelos pesquisadores estava na maneira como o apply_patch calculava as permissões necessárias. A ferramenta concedia acesso de escrita ao diretório pai dos caminhos especificados no patch.
Ao incluir um caminho como /tmp, a lógica poderia acabar concedendo permissão de escrita para /, ampliando a área autorizada para praticamente todo o sistema de arquivos.
A exploração combinava essa falha com um link simbólico. Um arquivo apontado para .zshrc, dentro do diretório pessoal do usuário, podia ser utilizado para direcionar a operação de escrita para fora do workspace.
Uma segunda entrada no patch era usada para ampliar a permissão. Essa entrada não precisava resultar em uma alteração bem-sucedida, porque o simples processamento do caminho já influenciava o cálculo da área autorizada.
O resultado era uma operação que deveria estar limitada ao projeto conseguindo atingir um arquivo fora dele. No caso demonstrado, a alteração do .zshrc poderia fazer com que comandos fossem executados quando o usuário abrisse uma nova sessão do Zsh.
O Overpatch, portanto, não depende de uma vulnerabilidade no motor JavaScript. Ele mostra como uma pequena falha na validação de caminhos pode comprometer todo o modelo de permissões de um sandbox.
Por que essas falhas são importantes para agentes de IA
Heapjack e Overpatch têm implementações diferentes, mas os pesquisadores identificaram um princípio arquitetural em comum: parte do mecanismo que deveria impor a segurança estava localizada dentro do ambiente que precisava ser protegido.
No Heapjack, o segredo que diferenciava código confiável de código não confiável estava no mesmo heap que o código não confiável podia examinar.
No Overpatch, a ferramenta que calculava as permissões de escrita recebia informações controladas pela própria operação que deveria restringir.
Esse problema é particularmente relevante para agentes de IA porque eles combinam interpretação de instruções, execução de comandos e acesso a arquivos. Uma vulnerabilidade em qualquer uma dessas camadas pode transformar uma instrução aparentemente inofensiva em uma cadeia de exploração.
Por isso, o isolamento não deve depender exclusivamente de verificações realizadas pelo próprio processo que executa o agente. A Accomplish AI defende uma arquitetura na qual o agente inteiro, incluindo shell, Git e processos iniciados por ele, permanece dentro de uma máquina virtual, enquanto credenciais reais e mecanismos críticos ficam fora desse ambiente.
Como se proteger das vulnerabilidades no OpenAI Codex
A principal medida é atualizar o Codex. Segundo a Accomplish AI, o Codex Desktop deve estar na versão 26.818.21641 ou posterior, enquanto o Codex CLI deve estar na versão 0.149.0 ou posterior para eliminar as vulnerabilidades descritas.
Para ambientes de desenvolvimento, a atualização deve fazer parte de uma estratégia mais ampla de defesa em profundidade. Algumas medidas são especialmente importantes:
- Usar contêineres ou máquinas virtuais para trabalhar com repositórios que não são totalmente confiáveis.
- Evitar disponibilizar ao agente tokens, chaves SSH e credenciais de produção desnecessários.
- Não expor sockets administrativos ou interfaces privilegiadas ao ambiente do agente.
- Manter Node.js, sistema operacional, dependências e ferramentas de desenvolvimento atualizados.
- Utilizar o modo de sandbox mais restritivo compatível com a tarefa.
- Revisar alterações automáticas em arquivos como
.zshrc,.bashrce outros arquivos de inicialização. - Separar ambientes de desenvolvimento, homologação e produção.
- Tratar código de terceiros como entrada potencialmente não confiável, mesmo quando a tarefa seja apenas revisar ou corrigir o projeto.
Também é importante não confundir um sandbox com uma garantia absoluta de segurança. O isolamento reduz a superfície de ataque, mas sua eficácia depende da implementação correta de cada componente responsável por impor as restrições.
As descobertas de Heapjack e Overpatch mostram justamente esse ponto. Um agente de IA pode estar limitado por permissões aparentemente rigorosas e, ainda assim, uma falha em uma camada intermediária permitir que essas restrições sejam contornadas.
Para desenvolvedores, profissionais de DevOps e administradores Linux, a principal lição é tratar agentes capazes de executar código como componentes potencialmente não confiáveis. Atualizar o Codex é essencial, mas manter credenciais separadas e uma camada adicional de isolamento pode limitar significativamente o impacto de uma futura vulnerabilidade.
Se você utiliza o OpenAI Codex, vale conferir agora a versão instalada e revisar quais arquivos, credenciais, sockets e recursos do sistema estão acessíveis ao agente. Em ambientes mais sensíveis, adicionar uma camada externa de isolamento, como Docker, máquinas virtuais ou ambientes de desenvolvimento descartáveis, pode reduzir o risco de uma falha no sandbox comprometer o computador hospedeiro.
