Duas maneiras de sair da sandbox do OpenAI Codex: Heapjack e Overpatch

Em 15 de setembro de 2026, Oren Yomtov, pesquisador principal de segurança da Accomplish AI, publicou um relato técnico sobre duas formas distintas de escapar do sandbox que envolve o agente de programação Codex da OpenAI. Ambas foram reportadas à OpenAI em 12 de agosto de 2026 e ambas foram corrigidas em até oito dias, segundo seu relato: Heapjack no Codex Desktop build 26.818.21641 e Overpatch no Codex CLI 0.149.0. Heapjack é o mais grave dos dois. Ele não exige nada da pessoa atacada além de abrir um repositório no Codex e fazer uma pergunta sobre o código, e é executado no modo somente leitura, o modo mais restritivo oferecido pelo produto, sem solicitação de aprovação e sem nada exibido na tela. Nenhum CVE foi atribuído a qualquer uma das duas falhas e nenhum comunicado independente da OpenAI foi publicado, segundo a Cloud Security Alliance, e não há relatos de pessoas prejudicadas por elas. Ele está catalogado ao lado das outras entradas de controle de agentes do ano em o arquivo de incidentes de IA, onde cada registro traz seus documentos de origem, grau de confiança e indicador de contestação.

Heapjack: o token estava em um heap que o lado não confiável podia ler

O Codex Desktop não pergunta antes de instalar o componente que Yomtov atacou. No momento da instalação, ele grava um bloco node_repl no arquivo de configuração global em ~/.codex/config.toml, e Yomtov relata que não há opt-in nem configuração que o desative. Como a entrada fica na configuração compartilhada, e não em uma escolha por usuário, um usuário comum do Codex CLI herda a mesma ferramenta sem nunca ser consultado.

A ferramenta node_repl é, ela própria, um programa nativo executado fora do sandbox. Ela pode abrir aplicativos, conectar-se a sockets Unix e editar o arquivo de configuração global. O que ela inicia dentro do sandbox é um único processo Node.js, e esse processo abriga dois contextos de execução JavaScript: um confiável, que contém o próprio código da OpenAI, e um não confiável, que executa o que quer que tenha sido solicitado ao agente.

O contexto confiável prova que é confiável apresentando um token aleatório, gerado do zero a cada execução. Isso deve ser a fronteira entre os dois contextos. Não é, porque ambos os contextos vivem em um único isolate V8 compartilhando um único heap de memória, então o token é uma string que está na memória e que o código não confiável pode ler. Um comentarista que reagiu à divulgação no X colocou o ponto de forma mais direta, em uma frase citada pela BleepingComputer: "Os contextos do V8 isolam os globais, não a memória, então a sandbox era na verdade uma promessa que o heap nunca aceitou." Isso é uma caracterização, não evidência; a evidência é a prova de conceito.

O exploit de Yomtov faz exatamente o que essa descrição implica. JavaScript não confiável chama v8.getHeapSnapshot(), examina o snapshot resultante em busca de strings com formato de UUID e testa cada candidata. Um palpite errado retorna "não autorizado". Um token correto emparelhado com um argumento inválido retorna, em vez disso, um erro de validação genuíno. A diferença entre as duas mensagens de erro é o oráculo que identifica o valor correto.

Com o token em mãos, o processo em sandbox grava sua própria requisição JSON no descritor de arquivo 1 — o mesmo pipe de stdout que o contexto confiável usa para alcançar o processo pai nativo. O processo pai valida o token, confirma que é válido e executa o trabalho. Na prova de conceito, esse trabalho era o comando open do sistema, que entrega a requisição ao launchd e inicia o aplicativo completamente fora da árvore de processos do Codex. O mesmo token permite conexões com sockets Unix arbitrários, entre eles o socket do daemon do Docker, e alcança uma ferramenta para editar o arquivo de configuração global.

Tudo isso roda em modo somente leitura, o modo que um usuário cauteloso seleciona justamente porque o repositório à sua frente não é confiável. Nenhum prompt de aprovação apareceu em nenhum momento. O cenário prático é curto: abra um repositório clonado no Codex, em modo somente leitura, e faça uma pergunta sobre o código. Quem escreveu esse repositório obtém execução de comandos sem sandbox na máquina, e nada na tela indica isso.

Overpatch: uma ferramenta de patch que concedia o pai de tudo o que tocava

A segunda falha está no Codex CLI, o agente de linha de comando de código aberto, e é um bug de permissões, não de memória. No modo workspace-write, o agente pode gravar dentro da pasta do projeto e em nenhum outro lugar; um comando de shell direcionado ao diretório home é recusado. A ferramenta apply_patch deveria manter essa regra. Em vez disso, ela derivava suas permissões dos caminhos nomeados no patch que estava aplicando e concedia acesso de gravação ao diretório pai de cada um deles.

Nomeie um caminho sob /tmp em um patch e a concessão se amplia até a raiz do disco, porque o pai de /tmp é /. Esse é todo o truque.

O exploit funcional usa duas entradas em um único patch. A primeira nomeia /tmp e não faz nada útil — ela falha, já que um arquivo não pode sobrescrever um diretório — e existe apenas para ampliar a permissão concedida. A segunda acrescenta uma linha ao .zshrc por meio de um symlink para o diretório home. Remova a primeira entrada e a gravação é recusada. Mantenha-a, e o próximo terminal que o desenvolvedor abrir executará a linha do atacante sem sandbox, com o sandbox completamente fora do circuito.

Isso torna o Overpatch um bug de persistência, e não algo de execução única. O arquivo de inicialização envenenado é executado novamente em cada shell que o desenvolvedor abre, até que alguém leia o .zshrc e perceba a linha acrescentada — e é por isso que a orientação da Cloud Security Alliance é procurar por ele em vez de esperar por um sintoma.

Ambos os bugs colocam a aplicação da regra dentro da própria coisa à qual ela se aplica.

A própria formulação de Yomtov é a parte que vai além do Codex. O apply_patch calculava suas próprias permissões a partir de entrada fornecida por um atacante. O node_repl mantinha na memória o segredo que separa código confiável de código não confiável, memória essa que o código não confiável podia ler. Em cada caso, disse-se à sandbox, a partir de dentro, para deixar algo passar.

A forma não é nova. O BleepingComputer, que noticiou a divulgação em 20 de setembro de 2026, observa que, em julho de 2026, pesquisadores da Pillar Security demonstraram a mesma ideia em Cursor, Codex, Gemini CLI e Antigravity, do Google, em que um agente que permanece dentro de sua sandbox grava um arquivo que uma ferramenta confiável fora da sandbox executa depois. O que distingue o par do Codex é o bypass de somente leitura no Heapjack e a ausência de qualquer configuração para desativar o componente que o carrega.

As correções, e o que a OpenAI disse e não disse

A OpenAI corrigiu o Heapjack no Codex Desktop build 26.818.21641 e o Overpatch no Codex CLI 0.149.0, segundo a Accomplish. Ambos chegaram dentro de oito dias após o relatório de 12 de agosto — até 20 de agosto, numa leitura simples dessa cronologia — e Yomtov creditou à OpenAI a reviravolta.

A OpenAI não publicou nenhum aviso de segurança independente para nenhuma das duas falhas, e nenhum identificador CVE foi atribuído; a Cloud Security Alliance registra ambas as ausências em uma nota de pesquisa datada de 22 de setembro de 2026. Questionado para comentar, um porta-voz da OpenAI disse ao BleepingComputer: "Agradecemos aos pesquisadores por entrarem em contato conosco e compartilharem suas descobertas. Resolvemos ambas as questões em agosto, mas estamos continuamente fortalecendo 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."

Essa declaração confirma as correções e não diz nada sobre os mecanismos. Ela não diz se as mudanças de agosto removeram o padrão de design ou fecharam os dois caminhos específicos de saída dele. Ninguém fora da OpenAI também disse isso.

O que está estabelecido, e o que depende de um único pesquisador

O arquivo classifica este registro como um achado de pesquisa, gravidade alta, região global, confiança B — documentado, mas proveniente de uma única fonte ou de fonte secundária — não contestado, sem dano real registrado. Esse grau é a lente certa para ler o restante deste texto, porque a divisão entre o que várias partes confirmam e o que apenas o descobridor afirma atravessa toda a história.

Estabelecido, no sentido de que mais de uma parte o afirma:

• A divulgação existe e está datada. O relato de Yomtov foi publicado em 15 de setembro de 2026; ambas as falhas foram comunicadas à OpenAI em 12 de agosto de 2026 e, segundo o seu próprio relato, corrigidas no prazo de oito dias.

• A OpenAI confirma que agiu em agosto. Seu porta-voz disse ao BleepingComputer que ambos os problemas foram tratados, o que corrobora o cronograma de relato e correção independentemente do descobridor, embora a empresa não tenha publicado nenhum aviso nem relato técnico próprio.

• As versões corrigidas são indicadas de forma consistente. A build 26.818.21641 do Codex Desktop e a versão 0.149.0 do Codex CLI são fornecidas pela Accomplish, repetidas pela BleepingComputer e veiculadas em um alerta de 22 de setembro de 2026 da Equipe Nacional de Resposta a Emergências Cibernéticas e Centro de Coordenação de Uganda, que classificou o par como "Vermelho".

• Nenhum CVE, nenhum aviso do fornecedor e nenhuma exploração reportada. A nota da Cloud Security Alliance de 22 de setembro de 2026 registra a ausência tanto de um CVE quanto de um aviso independente da OpenAI, e não relata nenhum caso confirmado de uma organização que tenha encontrado o mecanismo de persistência do Overpatch em funcionamento.

• O arquivo não contesta nada disso. O registro está marcado como disputado: falso, e sua classificação de confiança reflete o padrão de fontes, e não qualquer discordância sobre os fatos.

Não estabelecido, ou estabelecido por ninguém além de quem o encontrou:

• O detalhe do mecanismo é de Yomtov. O oráculo de heap snapshot, o descritor de arquivo compartilhado, a concessão de diretório pai — tudo isso vem do relato e da prova de conceito dele. A Cloud Security Alliance, cuja nota é o resumo de terceiros mais detalhado em circulação, descreve ter sintetizado o relato dele e a reportagem do BleepingComputer, e não afirma ter reproduzido qualquer um dos exploits nem testado qualquer uma das correções. O aviso do CERT.UG compila o mesmo material.

• Os intervalos de versões vulneráveis nunca foram publicados. Apenas as versões corrigidas são indicadas, portanto não há uma lista de quais builds anteriores continham cada falha.

• Não é declarado se uma instalação corrigida está segura contra a classe do bug, em vez de apenas contra estas duas instâncias. O “fortalecer continuamente nossas sandboxes” da OpenAI é um compromisso geral, não uma afirmação sobre um mecanismo específico.

• Não há registro de ninguém explorando qualquer uma das duas falhas. Isso é ausência de relatos, não a constatação de uma ausência, e a prova de conceito mostra que o caminho do Heapjack não deixa nada na tela que o usuário possa perceber.

O que um usuário pode acionar

Qualquer pessoa usando uma build do Codex Desktop anterior a 26.818.21641, ou uma versão do Codex CLI anterior a 0.149.0, está no lado vulnerável da linha que a Accomplish estabelece, e atualizar é o único remédio que a divulgação oferece. Além disso, a Cloud Security Alliance recomenda auditar sessões anteriores do Codex Desktop que envolveram repositórios não confiáveis em busca de atividade do launchd ou do open e de conexões com o socket do Docker, além de ler os arquivos de inicialização do shell — .zshrc, .bashrc e equivalentes — em busca de comandos que foram acrescentados, e não escritos pelo usuário.

A mesma nota desaconselha tratar o modo somente leitura como proteção quando o repositório não é confiável, que é a conclusão a que o próprio Heapjack chega por conta própria. As suas recomendações estruturais vão mais longe: isolamento físico de processos e de memória em vez de segredos compartilhados e convenções, credenciais mantidas fora do alcance do agente e patches que fazem referência a caminhos fora do projeto tratados como suspeitos à primeira vista. Essas são propostas de um terceiro. Não se sabe publicamente se a OpenAI adotou alguma delas além dos dois incrementos de versão.

Duas coisas merecem ser mantidas separadas ao final. Uma é um par de bugs em um agente de programação amplamente usado, relatados em 12 de agosto de 2026, corrigidos em oito dias e encerrados em dois números de build. A outra é a questão de design que Yomtov nomeia — se um sandbox pode ser imposto pelo código que ele deveria conter — e essa pergunta não é algo que um número de versão responde. Nem a Accomplish nem a OpenAI disseram que as mudanças de agosto resolvem isso.