Falha no Codex, da OpenAI, colocou releases no npm em risco, dizem pesquisadores da Depi
Aprofundamento CEVIU
Aprofundamento
A OpenAI corrigiu uma cadeia de falhas no Codex que, segundo a Depi, ligava prompt injection, escape de sandbox e credenciais de publicação no npm. Os pesquisadores Pierre Martin (Worty) e Garance de la Brosse (Madder) publicaram o estudo em 11 de novembro de 2026 e disseram ter reportado o problema pelo Bugcrowd. A divulgação não relata release malicioso publicado nem identifica usuários afetados.
O ponto de partida era um workflow do GitHub Actions que usava o Codex para sugerir rótulos em issues. Qualquer pessoa podia acioná-lo abrindo uma issue. Instruções plantadas no texto levaram o agente a rodar comandos de shell. Esses comandos ficavam dentro de um sandbox, mas pipes de debugging do .NET expostos em um diretório temporário compartilhado permitiram ler a memória do processo do runner fora desse limite. Credenciais removidas do ambiente do agente continuavam na memória, e foram extraídas pelos logs do workflow apesar do bloqueio de rede. Depois, um token roubado envenenou um cache de build, para executar um teste Python em um workflow Rust com mais permissões. A etapa final exigia uma ação de um maintainer: apagar uma release falsa, o que dispararia um workflow do atacante e daria um token de identidade para publicar no npm. O pacote @openai/codex teve cerca de 96,8 milhões de downloads entre 12 de outubro e 10 de novembro, mas isso mede downloads, não desenvolvedores afetados.
Há limites. A Depi cita o Codex Action v1.7, mas não informa versão afetada do Codex CLI nem data da correção. A técnica de cache poisoning já não vale para workflows em risco, porque o GitHub tornou somente leitura os tokens de cache da branch padrão em gatilhos não confiáveis, anúncio de 26 de junho. Segundo a Depi, o usuário não precisa instalar patch para esta cadeia. A recompensa inicial foi de US$ 1.000, com o relatório ainda em revisão. Os detalhes vêm do artigo original.
O que mudou
O caso se soma a uma sequência de achados sobre o Codex. Em 31 de março de 2026, o CEVIU noticiou "OpenAI Corrige Falhas de Exfiltração de Dados no ChatGPT e Vulnerabilidade de Token do Codex no GitHub". Em 21 de setembro de 2026, veio "Falhas Críticas Permitem Escape de Sandbox do OpenAI Codex e Execução de Comandos em Host". Agora o foco muda do host do desenvolvedor para a cadeia de publicação do pacote, com o sandbox como etapa intermediária.
Por que isso importa
Para quem opera pipelines de CI/CD, a leitura é que agentes de IA lendo texto não confiável (issues, títulos) merecem o mesmo cuidado de qualquer entrada externa. Em 20 de fevereiro de 2026, o CEVIU publicou "Comprometendo Lançamentos de Produção da Cline via Prompt em Bot de Triagem", e em 2 de junho de 2026, "Um único issue no GitHub era suficiente para comprometer toda a supply chain do Claude Code". O padrão se repete: revisar permissões de workflows, isolar credenciais da memória do runner e separar jobs que processam entrada pública dos que publicam.
Linha do tempo
CEVIU noticia correção da OpenAI para falhas no ChatGPT e vulnerabilidade de token do Codex no GitHub.
CEVIU noticia falhas que permitiam escape de sandbox do OpenAI Codex e execução de comandos no host.
Depi detalha cadeia de ataque ao Codex que colocava releases do npm em risco; a OpenAI já havia corrigido.
Perguntas frequentes
Alguém publicou uma versão maliciosa do @openai/codex no npm?
A divulgação da Depi não relata release malicioso publicado nem usuários afetados. A OpenAI corrigiu a falha antes disso. O número de 96,8 milhões de downloads mensais mostra o alcance potencial do pacote, não infecções.
Preciso instalar algum patch?
Segundo a Depi, a correção da OpenAI é do lado do projeto, então usuários não precisam instalar patch para esta cadeia. A pesquisa cita o Codex Action v1.7, mas não informa versão afetada do Codex CLI nem data da correção.
Como o ataque começava?
Com uma issue aberta no GitHub, que qualquer pessoa podia criar. O texto continha instruções que levaram o Codex, no workflow de rotulagem, a executar comandos de shell em vez de apenas classificar o conteúdo.
O ataque era totalmente automático?
Não. A etapa final dependia de um maintainer apagar uma release falsa, o que acionaria um workflow do atacante e geraria um token de identidade para publicar no npm. Além disso, a técnica de cache poisoning já não vale para workflows em risco, após mudança do GitHub.
Fontes
- thedefiant.iofonte original
- Categoria
- CEVIU Segurança da Informação
- Publicado
- 12 de novembro de 2026
- Editoria
- CEVIU Segurança da Informação

