`CVE-2025-61260` permite injeção de comando no OpenAI Codex CLI por configuração local do projeto

Falha no carregamento de CODEX_HOME e de servidores MCP permitia executar comandos definidos no repositório quando um desenvolvedor iniciava o codex dentro do projeto.

Componente	OpenAI Codex CLI com resolução de configuração via CODEX_HOME e carregamento de servidores MCP definidos em ./.codex/config.toml.
Vetor	Repositório contendo .env com CODEX_HOME=./.codex e arquivo ./.codex/config.toml com entradas mcp_servers que declaram command e args.
Impacto	Execução silenciosa de comandos no contexto do usuário que roda codex, com risco de shell reverso, exfiltração de segredos, persistência em fluxos de desenvolvimento e contaminação de CI/CD.
Prioridade	Atualizar o Codex CLI para a versão 0.23.0 ou posterior e bloquear configurações de projeto que redirecionem CODEX_HOME ou executem servidores MCP sem revisão.
Versões	A correção foi disponibilizada em 0.23.0, publicada em 20 de agosto de 2025, bloqueando o redirecionamento silencioso de CODEX_HOME para diretórios do projeto.
Artefatos	.env, CODEX_HOME, ./.codex/config.toml, mcp_servers, command, args e execução do comando codex dentro do repositório.
Mitigação	Remover confiança implícita em arquivos de configuração versionados, revisar commits que adicionem .codex ou .env, e auditar estáções e pipelines que tenham executado codex em repositórios não confiáveis.

Resumo técnico

A vulnerabilidade CVE-2025-61260 afeta o OpenAI Codex CLI em um ponto sensível da cadeia de confiança entre o terminal do desenvolvedor e os arquivos versionados de um projeto. O problema ocorre quando o utilitário é iniciado dentro de um repositório que contém um arquivo .env capaz de alterar CODEX_HOME para um caminho relativo, como ./.codex, e um arquivo ./.codex/config.toml com definições de servidores MCP. Nessa condição, o CLI resolvia a configuração para dentro do próprio repositório, interpretava as entradas mcp_servers como material confiável e executava o command com seus respectivos args durante a inicialização, sem uma etapa interativa de aprovação ou validação adicional.

O impacto técnico é mais próximo de execução remota de código acionada por fluxo de desenvolvimento do que de uma simples má configuração local. Um invasor que consiga inserir ou aprovar uma alteração em um repositório, modelo de projeto, dependência de exemplo ou base interna pode transformar arquivos aparentemente administrativos em um gatilho de execução. A vítima não precisa executar um script explícito do atacante; basta clonar ou atualizar o projeto e iniciar codex dentro dele. Como o comando roda no contexto do usuário, o alcance inclui arquivos locais, credenciais disponíveis no ambiente, chaves SSH, tokens de nuvem, configurações de Git, segredos usados por ferramentas de build e acesso a redes internas permitidas pela estáção.

A falha também quebra uma expectativa central de isolamento: arquivos fornecidos pelo projeto não deveriam se tornar instruções executáveis privilegiadas apenas por estarem no caminho de configuração efetivo. O risco aumenta em equipes que usam assistentes de linha de comando como parte de tarefas recorrentes, revisão de código, automação local ou agentes em pipelines. A correção foi publicada no Codex CLI 0.23.0 em 20 de agosto de 2025 e impede que arquivos .env redirecionem silenciosamente CODEX_HOME para diretórios do projeto, encerrando o caminho automático que permitia carregar e executar configurações MCP controladas pelo repositório.

Fluxo técnico

A cadeia começa com dois artefatos versionáveis. O primeiro é um .env no repositório que define CODEX_HOME=./.codex. O segundo é ./.codex/config.toml, contendo uma ou mais entradas mcp_servers com campos de comando e argumentos. Ao iniciar, o Codex CLI avaliava o ambiente, resolvia o diretório de configuração a partir de CODEX_HOME, carregava o arquivo TOML localizado nesse diretório e materializava os servidores MCP declarados para uso no tempo de execução. Na implementação vulnerável, essa materialização não se limitava a registrar metadados: o comando indicado na entrada MCP podia ser invocado imediatamente como parte do fluxo esperado de inicialização.

A pré-condição principal é a capacidade do atacante de fazer esses arquivos chegarem ao ambiente da vítima. Isso pode ocorrer por commit direto, pull request aprovado, comprometimento de um repositório, alteração em template, inclusão em projeto de exemplo ou modificação em uma base compartilhada usada por várias equipes. Depois que os arquivos estão presentes, o gatilho é operacionalmente banal: executar codex dentro do diretório do projeto. A ausência de prompt, de validação secundária e de nova aprovação quando command ou args mudam reduz a chance de detecção pelo usuário, especialmente quando a entrada MCP inicial parece legítima e é trocada posteriormente por uma carga maliciosa.

O comando executado herda o material analisado ao processo do usuário. Em uma estáção de trabalho, isso pode permitir leitura de variáveis de ambiente, arquivos de configuração, tokens de provedores de nuvem, credenciais de registro de pacotes, chaves privadas acessíveis pelo usuário, histórico de shell e conteúdo do repositório. Em um executor de CI/CD, o mesmo padrão pode atingir segredos de pipeline, tokens de publicação, permissões de escrita em artefatos, credenciais temporárias de infraestrutura e permissões de deploy. A exploração demonstrada incluiu payload determinístico de criação de arquivo e substituição por shell reverso; a técnica não depende de uma vulnerabilidade adicional no sistema operacional, porque a execução é delegada pelo próprio fluxo de configuração do CLI.

Há um aspecto importante de persistência lógica. Como a confiança era associada ao local de configuração resolvido e não ao conteúdo imutável da entrada, um arquivo inicialmente benigno podia atravessar revisão com menor suspeita e ser alterado depois para executar outro comando. Esse comportamento favorece ataques em duas fases: primeiro estabelecer a aceitação da estrutura .codex, depois trocar os argumentos ou o binário invocado. Em repositórios com revisão superficial de arquivos auxiliares, a mudança pode passar despercebida, principalmente se o nome do servidor MCP ou do comando aparentar estar relacionado a automação legítima do projeto.

Superfície afetada

A superfície exposta inclui qualquer ambiente que execute versões vulneráveis do Codex CLI dentro de um repositório controlado total ou parcialmente por terceiros. Isso abrange estáções de desenvolvedores, máquinas de revisão, ambientes de treinamento, runners de CI/CD, agentes de automação e containers de build que preservem variáveis e arquivos suficientes para que codex carregue a configuração local. O risco é maior quando a execução do CLI faz parte de hábitos recorrentes, porque o acionamento não se parece com a execução de um instalador, hook ou script suspeito; ele ocorre durante uma ação esperada do fluxo de desenvolvimento.

Projetos colaborativos têm exposição particular. Um atacante não precisa comprometer o binário do Codex CLI nem explorar uma falha de memória. A técnica usa o próprio mecanismo de configuração do produto e a semântica de MCP para transformar arquivos do repositório em instruções executáveis. Em projetos públicos, o vetor pode aparecer em templates, exemplos de integração, forks populares ou alterações que prometem melhorar automação. Em projetos privados, o vetor pode surgir por conta de credenciais Git comprometidas, conta de colaborador abusada, dependência de repositório interno ou alteração em base compartilhada de engenharia.

Ambientes de CI/CD devem ser tratados como área crítica quando qualquer job executou codex sobre código recém-obtido do controle de versão. Se o runner possuía segredos de publicação, permissões de push, acesso a registros de container, credenciais de nuvem ou tokens para abrir pull requests, a execução de um comando MCP malicioso pode ter ultrapassado a estáção individual e alcançado a cadeia de build. Mesmo quando o payload não deixa binários persistentes, comandos de exfiltração via rede, modificação de artefatos ou coleta de variáveis podem produzir impacto fora do host original.

Sistemas corrigidos com Codex CLI 0.23.0 ou posterior reduzem o caminho de exploração descrito porque a correção bloqueia o redirecionamento silencioso de CODEX_HOME por .env para diretórios do projeto. Ainda assim, equipes devem revisar repositórios que tenham incorporado .codex/config.toml e .env antes da atualização, pois o histórico pode indicar tentativa de exploração, teste indevido ou persistência em fluxos não mais acionados pelo binário corrigido.

• Estáções de desenvolvedores que executaram codex em repositórios contendo .env com CODEX_HOME=./.codex.
• Repositórios com diretório ./.codex versionado e entradas mcp_servers declarando command e args.
• Pipelines, runners ou agentes de build que iniciaram Codex CLI sobre código recém-clonado ou atualizado.
• Templates, starter repos e projetos de exemplo usados como base por múltiplas equipes ou consumidores downstream.

Hunting e telemetria

A investigação deve começar pelo controle de versão. Procure commits que adicionem ou alterem .env, ./.codex/config.toml, diretórios .codex versionados e blocos mcp_servers. A revisão precisa comparar não apenas a presença da configuração, mas também mudanças nos valores de command e args, porque a técnica permite uma entrada inicialmente inofensiva ser substituída por comando de rede, shell, execução de interpretador ou coleta de arquivos. Em Git, priorize diffs em pull requests recentes, alterações de colaboradores novos, commits feitos perto de incidentes de credenciais e mudanças sem justificativa operacional clara.

Em endpoints, a telemetria útil é a relação pai-filho entre o processo codex e comandos inesperados. Procure execução de shells, interpretadores, utilitários de rede, ferramentas de transferência, comandos de compactação ou leitura de segredos iniciados a partir do processo do CLI. Em Windows, criação de processos como powershell.exe, cmd.exe, wscript.exe, curl.exe ou binários incomuns com pai relacionado ao Codex deve ser examinada. Em Linux e macOS, observe /bin/sh, bash, zsh, python, node, curl, wget, nc, openssl, ssh e chamadas que leiam diretórios de credenciais ou arquivos de configuração do usuário.

A análise de rede deve buscar conexões iniciadas logo após a execução de codex em um repositório suspeito. Shell reverso e exfiltração podem aparecer como sessões TCP para destinos externos incomuns, requisições HTTP com conteúdo de arquivos, conexões para infraestrutura recém-criada ou tráfego saindo de runners que normalmente só acessam serviços internos e registros conhecidos. Como o payload é livre, não há IoC universal; a defesa depende de encadear evento de processo, caminho do repositório, hash do arquivo de configuração, usuário, horário e destino de rede.

Em CI/CD, revise logs de jobs que invocaram codex, variáveis expostas ao processo, artefatos publicados, alterações subsequentes em imagens, pacotes ou releases e qualquer uso anômalo de tokens após a execução. Quando houver suspeita de exposição, trate segredos acessíveis pelo runner como comprometidos, mesmo que o log não mostre a carga completa. Muitos sistemas mascaram tokens em saída textual, mas isso não impede que um processo malicioso os use diretamente para chamadas autenticadas.

• Commits ou pull requests adicionando .env com CODEX_HOME=./.codex.
• Entradas mcp_servers novas ou alteradas em ./.codex/config.toml, especialmente mudanças em command e args.
• Processos filhos inesperados de codex, incluindo shells, interpretadores, clientes HTTP, ferramentas de rede e comandos de leitura de arquivos sensíveis.
• Conexões de saída iniciadas imediatamente após uso do Codex CLI em repositórios com configuração local.
• Uso anômalo de tokens de Git, nuvem, registro de pacotes ou CI/CD após jobs que executaram codex.

Mitigação

A primeira ação é atualizar o Codex CLI para 0.23.0 ou versão posterior em estáções, imagens de desenvolvimento, containers, runners e qualquer ambiente automatizado que execute o utilitário. A atualização deve ser verificada por inventário, não apenas comunicada aos usuários, porque a vulnerabilidade depende do binário efetivamente executado. Em máquinas com múltiplas instalações, confirme o caminho resolvido no PATH, versões instaladas por gerenciadores diferentes e imagens base usadas por pipelines. A correção publicada impede que .env redirecione silenciosamente CODEX_HOME para dentro do repositório, removendo o gatilho automático descrito.

Depois da atualização, trate o histórico de repositórios como fonte de evidência. Localize ocorrências de .codex/config.toml, .env e CODEX_HOME; remova configurações que não sejam necessárias; e exija revisão explícita para qualquer entrada MCP que execute comandos. Servidores MCP legítimos devem ter finalidade documentada, comando previsível, caminho controlado e escopo mínimo. Não permita que definições de projeto chamem shells genéricos ou interpretem argumentos derivados de arquivos não confiáveis sem controle adicional.

Quando houver indício de que a cadeia foi acionada, a resposta deve incluir contenção de credenciais. Revogue e recrie tokens de nuvem, chaves de deploy, credenciais de registro de pacotes, tokens de Git, segredos de CI/CD e chaves SSH que estavam acessíveis ao usuário ou runner no período de exposição. Em seguida, valide se não houve publicação de artefatos adulterados, criação de contas, alteração de permissões, novos webhooks, runners registrados indevidamente ou mudanças em pipelines. A ausência de payload visível em logs não elimina risco, pois o comando pode ter executado de forma silenciosa e usado canais externos.

Como controle preventivo, imponha políticas de revisão para arquivos de configuração executável em repositórios. Bloqueios em pre-commit, regras de proteção de ramo e scanners de pull request podem sinalizar alterações em .env, CODEX_HOME, .codex/config.toml e mcp_servers. Em endpoints, regras de EDR devem alertar quando codex iniciar processos de shell ou ferramentas de rede fora de uma lista permitida. Em CI/CD, execute assistentes de desenvolvimento com credenciais mínimas, rede restrita e ambientes descartáveis, evitando que um comando iniciado por configuração de projeto tenha acesso amplo a segredos persistentes.

• Atualizar todas as instalações do Codex CLI para 0.23.0 ou posterior e confirmar o binário realmente usado no PATH.
• Pesquisar e revisar .env, CODEX_HOME, ./.codex/config.toml e blocos mcp_servers em repositórios ativos e históricos.
• Bloquear ou exigir aprovação de segurança para entradas MCP que definam command e args em arquivos versionados.
• Criar detecções para processos filhos de codex que invoquem shells, interpretadores, clientes de rede ou comandos de coleta de credenciais.
• Rotacionar segredos acessíveis a estáções e pipelines quando houver evidência de execução em repositório suspeito.
• Executar jobs com privilégios mínimos, rede controlada e tokens de curta duração para reduzir o impacto de comandos acionados por configuração.