editorially independent. We may make money when you click on links
to our partners.
Learn More
Developers using OpenAI’s Codex CLI may be unknowingly executing attacker-supplied commands the moment they run the tool inside a compromised repository.
A newly disclosed flaw shows how simple project files like .env and config.toml can be turned into silent, reproducible execution vectors in everyday development workflows.
The result is a supply-chain weakness that requires no social engineering, no trick binaries, and no user approval.
The vulnerability creates “… a stealthy, reproducible supply-chain backdoor that triggers on normal developer workflows,“ said Check Point researchers.
The Codex Config Flaw Behind This Stealth RCE
At its core, CVE-2025-61260 is a command injection vulnerability triggered by Codex’s implicit trust in project-local configuration files.
During startup, Codex resolves its configuration path, loads MCP server definitions, and automatically invokes the declared command and args.
The problem is this happens without secondary validation, without user confirmation, and without re-approval if the configuration changes later.
This means an attacker with commit or pull-request permissions can:
- Redirect CODEX_HOME using a project .env file
- Add a .codex/config.toml with an MCP entry
- Embed any shell command (file operations, credential exfiltration, a reverse shell, etc.)
When the developer later clones or updates the repo and runs codex, the payload executes instantly in the developer’s context.
In their proof-of-concept, researchers demonstrated both benign payloads (file creation) and more dangerous ones, such as launching a reverse shell or opening system applications.
Because no validation occurs when entries change, attackers can swap a harmless config for a malicious one post-merge, creating a stealthy supply-chain backdoor that persists across routine development operations.
From One Workstation to the Entire Pipeline
The real-world implications of the vulnerability extend beyond a single compromised workstation.
Developer environments typically hold high-value assets — cloud credentials, SSH keys, API tokens, container registry access, and source code — making them prime targets once an attacker gains a foothold.
A malicious command that executes silently at startup can provide persistent remote access each time Codex is run, enable the exfiltration of sensitive developer secrets and internal code, and allow lateral movement into cloud services or on-premise networks.
The risk doesn’t stop there: poisoned repositories can propagate through open-source templates, starter projects, or forks, while CI systems that run Codex during builds may inadvertently contaminate pipelines and downstream artifacts.
Because the attack vector is a standard repository commit, a single malicious payload can spread quickly across teams, contributors, and dependent projects, amplifying the blast radius across the entire software supply chain.
Hardening Codex in High-Risk Environments
Because Codex automatically trusts project-local files, organizations must adopt stronger controls around how and where the tool is used.
- Audit repositories for suspicious Codex configuration files, including .env files that override CODEX_HOME and unexpected .codex directories.
- Restrict or disable project-local Codex configurations and require centralized, approved configuration sources.
- Enforce strict PR and commit hygiene to flag and review any configuration or environment files that could trigger code execution.
- Monitor for anomalous Codex activity by logging shell commands, file-system changes, and outbound network traffic associated with Codex.
- Revoke and rotate all exposed developer credentials, tokens, and SSH keys, and reduce reliance on long-lived secrets.
- Run Codex in sandboxed or least-privilege environments such as isolated developer containers or locked-down workstations.
- Integrate Codex usage into enterprise security governance by establishing usage policies, training developers on risks, and routing Codex telemetry into SIEM and EDR tools.
These mitigations help organizations protect against silent code execution, protect credentials, and strengthen supply-chain defenses.
How Automation Is Expanding the Attack Surface
CVE-2025-61260 highlights a broader shift in the threat landscape: AI-enhanced developer tools are creating new trust boundaries that attackers are rapidly learning to exploit.
As tools increasingly automate code reading, modification, and execution, any implicit trust in project-supplied metadata becomes a powerful attack vector.
In this new environment, supply-chain compromises are no longer limited to malicious binaries — configuration files, environment variables, and workflow metadata are becoming prime targets.
As developer automation accelerates, organizations must recognize that the weakest link in the chain may now be the files that guide these AI-driven tools, not the code they ultimately produce.
Such evolving risks highlight how essential comprehensive software supply chain security has become.
