RespostasPublicado20 fontes
Heapjack e Overpatch: como falhas no sandbox do Codex permitiam escapar para o computador
Heapjack e Overpatch podiam contornar limites previstos do Codex e levar a ações no computador anfitrião a partir de um repositório não confiável. Heapjack explorava um helper node repl configurado globalmente e um heap V8 compartilhado; Overpatch explorava permissões do apply patch calculadas a partir de caminhos c...
Publicado porEditado com GPT-5.6 TerraImagens geradas com GPT Image 2
Resposta de pesquisa
Principais conclusões
- Heapjack e Overpatch podiam contornar limites previstos do Codex e levar a ações no computador anfitrião a partir de um repositório não confiável.
- Heapjack explorava um helper node repl configurado globalmente e um heap V8 compartilhado; Overpatch explorava permissões do apply patch calculadas a partir de caminhos controlados no patch.
- Outras falhas de agentes de programação em 2026, relacionadas a configurações do Git, tinham mecanismo diferente, mas a mesma fraqueza arquitetural: um caminho privilegiado fora do sandbox obedecia a dados controlados...
Prompt de IA
openai.comCreate a landscape editorial hero image for this Studio Global article: How did Accomplish AI researchers’ Heapjack and Overpatch vulnerabilities enable sandbox escapes and host-command execution in OpenAI’s Code. Article summary: Accomplish’s two findings bypassed Codex’s intended workspace/read-only boundaries by making a trusted enforcement component rely on attacker-influenced state. Both could turn an untrusted repository into host-level code. Topic tags: general, general web. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts with fake numbers, clic
O sandbox do Codex foi projetado para limitar o que um agente de programação com IA poderia ler, alterar e executar. As descobertas Heapjack e Overpatch, da Accomplish AI, mostraram que esse limite ainda podia ser contornado quando um componente confiável compartilhava um segredo com código não confiável ou derivava permissões de dados controlados pelo atacante. As duas falhas foram reportadas como corrigidas. 4
8
Heapjack: um segredo de autorização no heap compartilhado
O Heapjack afetava a integração node_repl instalada pelo Codex Desktop. Segundo os pesquisadores, o aplicativo Desktop colocava a configuração do servidor MCP no arquivo global ~/.codex/config.toml. Com isso, sessões do CLI que usassem essa configuração compartilhada também podiam herdar o helper. 8
9
A quebra de isolamento estava no runtime JavaScript do helper:
- um contexto confiável mantinha um token de autorização por execução;
- um contexto não confiável, controlado pelo agente, rodava no mesmo heap V8;
- o lado não confiável conseguia recuperar o token e usá-lo para fazer requisições que o processo nativo pai tratava como autorizadas.
8
15
Como esse processo pai operava fora do sandbox, o resultado podia incluir ações no sistema anfitrião, como execução de comandos, mesmo quando o Codex estava nominalmente no modo somente leitura. O problema não era apenas a execução de JavaScript: a credencial que separava trabalho confiável e não confiável ficava em memória acessível ao lado não confiável. 8
15
Overpatch: permissões ampliadas pelo conteúdo do patch
O Overpatch era uma falha do Codex CLI em apply_patch, no modo de escrita no workspace. A ferramenta deveria manter as edições dentro da área de trabalho, mas sua lógica de autorização concedia escopo de escrita com base nos diretórios-pai citados no próprio patch. 4
Isso tornava os caminhos do patch uma entrada sensível para a segurança. A Accomplish descreveu uma prova de conceito em que um caminho sem efeito prático, como /tmp, fazia a permissão se ampliar até a raiz do sistema de arquivos. Outra mudança no patch então seguia um link simbólico controlado pelo repositório para modificar um arquivo fora do workspace, incluindo um arquivo de inicialização do shell no diretório pessoal do usuário. 4
9
A consequência de segurança não era necessariamente imediata, mas era relevante: código inserido em um arquivo de inicialização do shell poderia ser executado fora do sandbox quando a pessoa desenvolvedora abrisse um terminal posteriormente. A ação no sistema anfitrião resultante não exigia o prompt normal de aprovação. 4
7
O erro em comum: um componente privilegiado confiou na coisa errada
Heapjack e Overpatch seguiram caminhos técnicos diferentes, mas expõem o mesmo problema de projeto: o mecanismo de proteção confiava em dados alcançáveis a partir do lado não confiável da fronteira.
| Falha | O que era tratado como confiável | Por que a fronteira falhou |
|---|---|---|
| Heapjack | Um token de autorização em um heap V8 compartilhado | Código não confiável podia recuperar o segredo usado para distinguir requisições confiáveis. |
| Overpatch | Caminhos fornecidos em um patch controlado pelo agente | Esses caminhos influenciavam o escopo de permissões de escrita, em vez de apenas descreverem a edição pretendida. |
Trata-se de um problema de confused deputy: um helper ou orquestrador com mais privilégios executa uma ação em nome de uma entrada de menor confiança sem validar de forma segura a autoridade ou o destino final. Portanto, colocar apenas o shell do agente em sandbox não basta se helpers, tokens, configurações e subprocessos de orquestração continuarem privilegiados ou puderem ser influenciados pelo conteúdo do repositório.
Como os escapes ligados ao Git se encaixam nesse padrão
Outras descobertas de 2026 sobre sandboxes de agentes de programação eram tecnicamente diferentes, mas semelhantes na arquitetura. Os relatórios Beltdown e Beltdown2, da Accomplish, descreveram shells de agentes isolados enquanto comandos internos do Git, executados pelo orquestrador ao redor deles, rodavam fora do sandbox. A configuração core.fsmonitor em .git/config podia fazer o Git executar um helper configurado ao inspecionar a árvore de trabalho. 17
18
A Manifold Security chamou essa classe mais ampla de GitSpawn: uma configuração de Git controlada pelo repositório podia levar à execução de código escolhido pelo atacante quando o agente inspecionasse o projeto, potencialmente antes de uma decisão efetiva de confiança ou aprovação. 20
21
A lição não é que todo repositório seja automaticamente perigoso em qualquer fluxo de trabalho. É que repositórios devem ser tratados como entrada potencialmente ativa quando ferramentas inspecionam metadados, resolvem links simbólicos, aplicam patches, executam hooks ou iniciam processos auxiliares. A fronteira de confiança de um produto de agentes inclui todos esses caminhos — e não apenas a ferramenta de comandos visível.
Versões do Codex com correção
As versões mínimas reportadas com as correções são:
- Codex Desktop build 26.818.21641 ou posterior para o Heapjack.
9
- Codex CLI versão 0.149.0 ou posterior para o Overpatch.
4
A Accomplish afirmou que reportou as duas falhas à OpenAI em 12 de agosto de 2026 e que as correções chegaram em até oito dias. 9
O que fazer antes de abrir um repositório não confiável
- Atualize o aplicativo Desktop e o CLI. As falhas afetavam componentes diferentes, e o helper global instalado pelo Desktop podia afetar sessões do CLI que usassem a configuração compartilhada.
- Considere o conteúdo do repositório mais do que simples código-fonte. Links simbólicos, caminhos de patches, arquivos de configuração, hooks e metadados do Git podem influenciar o que o agente ou seu orquestrador faz.
20
- Mantenha recursos sensíveis do computador fora do ambiente. Evite expor credenciais de longa duração, chaves SSH, tokens de nuvem, sockets do Docker ou arquivos sensíveis do diretório pessoal ao avaliar código desconhecido.
- Use isolamento externo para projetos realmente não confiáveis. Uma máquina virtual descartável, ou ambiente com isolamento equivalente, cria uma barreira separada caso o agente, um helper ou o orquestrador seja comprometido.
- Tenha cuidado extra com repositórios recebidos intactos. Riscos no estilo GitSpawn são especialmente relevantes quando o projeto chega por arquivo compactado, unidade compartilhada, pasta sincronizada ou mídia removível que preserva os metadados
.git; um clone comum normalmente não transfere o.git/configlocal de um repositório remoto.22
Na prática, a recomendação é direta: atualize os componentes afetados do Codex, mas não trate um sandbox dentro do processo como a única barreira entre um repositório desconhecido e a estação de trabalho de desenvolvimento.
Studio Global AI
Continue sua pesquisa
Esta página inclui uma resposta baseada na fonte que você pode continuar em Studio Global.
As pessoas também perguntam
Qual é a resposta curta para "Heapjack e Overpatch: como falhas no sandbox do Codex permitiam escapar para o computador"?
Heapjack e Overpatch podiam contornar limites previstos do Codex e levar a ações no computador anfitrião a partir de um repositório não confiável.
Quais são os pontos-chave para validar primeiro?
Heapjack e Overpatch podiam contornar limites previstos do Codex e levar a ações no computador anfitrião a partir de um repositório não confiável. Heapjack explorava um helper node repl configurado globalmente e um heap V8 compartilhado; Overpatch explorava permissões do apply patch calculadas a partir de caminhos controlados no patch.
O que devo fazer a seguir na prática?
Outras falhas de agentes de programação em 2026, relacionadas a configurações do Git, tinham mecanismo diferente, mas a mesma fraqueza arquitetural: um caminho privilegiado fora do sandbox obedecia a dados controlados...
Fontes