OpenAI Codex CLI Auto-Loaded MCP Config Enables Command Injection Without Interactive Approval (CVE-2025-61260)

At a glance

• The issue: OpenAI's Codex command-line tool runs whatever Model Context Protocol (MCP) servers a project's .codex/config.toml specifies, without asking the user. Cloning a malicious repository and running codex inside it gives the repo's author code execution on your machine.
• Who's affected: Any developer using @openai/codex before version 0.23.0.
• What to do now: Upgrade @openai/codex to 0.23.0 or newer, and avoid running codex inside untrusted clones.

Executive Summary

OpenAI's Codex CLI (@openai/codex) before version 0.23.0 automatically loads a project-local .env file that can redirect CODEX_HOME into the repository itself, then parses ./.codex/config.toml and spawns any Model Context Protocol (MCP) server command listed in it, all at startup, with no interactive approval (CheckPoint Research). A malicious repository can therefore ship a pre-planted .env and .codex/config.toml that achieve arbitrary command execution the first time a developer runs codex inside a clone of that repository (CheckPoint Research). Exploitation requires the developer to invoke codex inside the attacker-controlled working tree; this is the tool's primary invocation path, not a separately engineered trigger (RAXE assessment). The issue is tracked as CVE-2025-61260 with a CNA-submitted CVSS 3.1 base score of 9.8 Critical; the NVD record status is Awaiting Analysis as of 2026-04-20 (NVD). OpenAI patched the issue in @openai/codex 0.23.0, published to npm on 2025-08-20 (npm registry).

Risk Rating

Affected Products

Am I Affected?

• Check package installation: run npm list -g @openai/codex or npx @openai/codex --version. If the version is below 0.23.0, the installation is affected (npm registry).
• Check invocation surface: any workflow that runs codex inside a recently cloned or updated third-party repository is an exposure path, code review, dependency evaluation, triage of external bug reports (RAXE assessment based on CheckPoint Research).
• Check CI/agent pipelines: automated agents that invoke codex against per-job working trees are also in scope (RAXE assessment).

Abstract

CVE-2025-61260 is an improper control of generation of code vulnerability (CWE-94) in versions of the OpenAI Codex CLI before 0.23.0 (NVD). The CLI loads a project-local .env before loading its own configuration; a .env that sets CODEX_HOME=./.codex redirects the configuration root into the repository, causing the CLI to parse ./.codex/config.toml and invoke its declared mcp_servers.*.command entries as subprocesses at startup, with no interactive approval (CheckPoint Research). The attack requires only that a target clone a prepared repository and run codex inside it; no network-reachable service, authentication bypass, or additional supply-chain compromise is necessary (CheckPoint Research). The disclosure timeline has three distinct events: CheckPoint Research reported the issue to OpenAI on 2025-08-07; OpenAI published the fix as @openai/codex 0.23.0 on 2025-08-20; CheckPoint Research published their public write-up on 2025-12-01; the NVD/CVE record (CVE-2025-61260) was published on 2026-04-14 (CheckPoint Research; npm registry; NVD). The fix was therefore public on npm throughout the subsequent eight-month window; the technical write-up followed at three-and-a-half months; the named-CVE record landed last.

Key Findings

1. The trigger is an ordinary developer workflow. Cloning an attacker-controlled repository and running codex inside it is sufficient; no elevated privileges, no authentication, and no Codex subcommand beyond the default invocation are required (CheckPoint Research).
2. The config root is environment-redirectable by design. CODEX_HOME is the documented switch that controls where the CLI looks for configuration; the vulnerability is that this switch can be set by a repository-shipped .env before the CLI validates its provenance (CheckPoint Research).
3. MCP server definitions are executed, not evaluated. The CLI's intended behaviour is to spawn declared MCP servers as helper subprocesses. With a project-local config.toml under attacker control, the spawn is the exploit primitive, no further parsing bug is required (CheckPoint Research).
4. The public CVSS vector is a defensible-but-contested UI rating. The CNA-submitted vector carries UI:N; the attack trigger requires the victim to run codex inside the attacker's repository. RAXE reads UI:R as the more accurate description, but this is a judgement call rather than a clear CNA error, CVSS 3.1's UI:R/UI:N line is contested where the triggering action is the tool's primary invocation. The base severity remains Critical under either interpretation (RAXE assessment, based on NVD vector and CheckPoint Research attack description).
5. NVD analysis is pending. The NVD record has vulnStatus: Awaiting Analysis as of 2026-04-20; all NVD-reported CVSS figures are CNA-submitted Secondary scores, not NVD-analysed (NVD).

Attack Flow

Attacker repo (public or invited-to)
  ├── .env            -> CODEX_HOME=./.codex
  └── .codex/
        └── config.toml
               [mcp_servers.X]
               command = "<attacker-chosen>"
               args    = ["<attacker-chosen>"]

        |
        | Victim clones or pulls repo
        v

Victim runs `codex` inside the working tree
        |
        v
Codex CLI < 0.23.0 startup sequence (CheckPoint Research):
  1. Reads ./.env   -> applies CODEX_HOME=./.codex to process env
  2. Resolves $CODEX_HOME/config.toml  (= ./.codex/config.toml)
  3. Parses [mcp_servers.*] entries
  4. Spawns command + args as subprocess   <-- arbitrary execution
                                                 in victim's shell context

Technical Details

Vulnerability mechanics

Codex CLI versions before 0.23.0 perform two configuration-loading steps at startup that combine into the vulnerability (CheckPoint Research):

1. The CLI reads the project-local .env file in the current working directory and applies the environment variable assignments it finds to the running process. No allow-list governs which variables may be set from .env.
2. After step 1, the CLI resolves the Codex configuration root from CODEX_HOME. Because step 1 can have just set CODEX_HOME, the root may now point into the repository itself.

The CLI then parses $CODEX_HOME/config.toml and, for each [mcp_servers.<name>] entry, spawns the declared command with args as a child process (CheckPoint Research). This subprocess runs with the user's privileges; there is no interactive confirmation, no user-visible notification, and no allow-list of permitted commands (CheckPoint Research).

Configuration artefacts

The two files required in the attacker-controlled repository are (CheckPoint Research):

./.env
    CODEX_HOME=./.codex

./.codex/config.toml
    [mcp_servers.<name>]
    command = "<attacker-chosen executable>"
    args    = ["<attacker-chosen arguments>"]

No working attacker payload is provided in this publication. The structural layout above is the disclosed exploitation surface and is sufficient for detection engineering.

Patch

OpenAI's fix in @openai/codex 0.23.0 prevents .env files from redirecting CODEX_HOME into project-local directories without user awareness, closing the auto-execution path (CheckPoint Research). Verified via the npm registry single-version manifest for @openai/codex@0.23.0: publish timestamp 2025-08-20T06:07:34.871Z, publisher mbolin@openai.com (the mbolin-openai npm account), repository git+https://github.com/openai/codex.git, tarball shasum e95d0775d17b4f3f0122d75f362f4642ee170a6a (npm registry, queried 2026-04-20). Version 0.22.0, the last pre-patch release, was published 2025-08-15T21:13:31.180Z; version 0.24.0 followed on 2025-08-26T17:44:37.233Z (npm registry). Evidence artefact preserved in the finding's validation/ directory.

Source-record provenance

The NVD description states "OpenAI Codex CLI v0.23.0 and before." Read literally this includes 0.23.0 among affected versions, which contradicts CheckPoint's statement that 0.23.0 is the fix. The npm registry's publish timestamp for 0.23.0 matches the CheckPoint-stated patch date (2025-08-20); RAXE therefore treats < 0.23.0 as affected and >= 0.23.0 as patched, and interprets the NVD phrasing as imprecise wording meaning "versions before 0.23.0" (RAXE assessment; npm registry; CheckPoint Research). Operators tracking this CVE in inventory tools should verify that the tool is applying the < 0.23.0 range rather than the <= 0.23.0 range a naive reading of NVD's sentence would produce.

Confidence & Validation

Assessment Confidence: High

Detection Signatures

Full Sigma rules are published in the finding directory:

• Codex_CLI_Project_Local_MCP_Subprocess (Sigma, process_creation): Codex spawning a non-runtime subprocess when its effective CODEX_HOME resolves inside the current working directory. Full rule: detection/codex-mcp-inject.yml (published alongside this advisory).
• Codex CLI Invoked Shortly After Git Clone Or Pull (Sigma correlation), HUNTING / DELIVERY TELEMETRY, not IOC-grade: correlates a git clone or git pull with a subsequent codex invocation within 60 seconds in the same user/host context. The rule does NOT directly observe the .env or .codex/config.toml read, Sigma process_creation telemetry cannot observe file-read events, which require Sysmon EventID 11 / auditd / EDR-native file-access signals instrumented separately. The rule therefore proxies "codex run shortly after a clone" as a hunting enrichment; on both affected and patched Codex it will fire on ordinary developer workflows. Deploy as audit-only to enrich other telemetry, not as a blocking detection. Full rule and deployment guidance: detection/codex-mcp-inject.yml.
• Codex_MCP_Inject_Env_Redirect (YARA): scans files for CODEX_HOME being set to a relative path inside a .env-like file. Full rule: detection/codex-mcp-inject.yar.
• Codex_MCP_Inject_Toml_MCPServers (YARA): scans TOML files for [mcp_servers.*] sections containing a command = "..." field. Full rule: detection/codex-mcp-inject.yar.
• Per-repository correlation note: the exploit layout requires both files in the same repo, which standard YARA cannot express within a single rule. The detection file publishes harness-level pseudocode (not a YARA rule) describing the correlation logic a scanner should implement: both per-file YARA rules must match in the same repository root, with the .env match at ./.env and the TOML match at ./.codex/config.toml. Full text in detection/codex-mcp-inject.yar.

Detection & Mitigation

Priority 1, patch. Upgrade @openai/codex to 0.23.0 or later. Verify with npm list -g @openai/codex (or the equivalent for project-scoped installs) that no 0.22.x or earlier installation remains on developer workstations (npm registry).

Priority 2, pre-clone inspection. Until every developer-workstation install is audited as patched, avoid running codex inside untrusted repositories without first inspecting them for a .env that sets CODEX_HOME or a .codex/config.toml that declares mcp_servers entries (RAXE assessment).

Priority 3, CI and agent scope. Any CI pipeline or automated agent that invokes codex against per-repository working copies should be moved behind a patched runtime and, where feasible, executed in a container or ephemeral VM that isolates it from developer credentials (RAXE assessment).

Priority 4, deploy the Sigma and YARA content referenced above to developer-workstation EDR and to repository-scanning CI jobs.

Residual risk after patch: The 0.23.0 fix targets the specific .env-driven CODEX_HOME redirection. Other environment-injection vectors that reach the same configuration-loading code path, for example shell-init files the user already trusts, per-directory environment loaders, or editor integrations, have not been ruled out by this research and are not in scope of the published fix (RAXE assessment).

Indicators of Compromise

No file-hash or network-indicator IoCs are available; the attack primitive is structural, not tied to a specific payload (RAXE assessment).

Strategic Context

CVE-2025-61260 is a specific instance of a broader class of weaknesses across agentic developer CLIs: project-local configuration files that are trusted as authoritative without regard to their provenance. The pattern is not unique to Codex; comparable trusted-domain, workspace-trust, and command-injection issues have been reported in other agentic developer CLIs over the past year. The common thread is a tool that inherits the trust level of the file system it opens rather than the trust level of the repository that placed those files there (RAXE assessment).

The mitigation, phrased generically, is that agentic CLIs must distinguish user-scoped trusted configuration (e.g., $HOME/.codex) from repository-scoped untrusted configuration, and must require explicit consent before running executables declared in the latter. Codex's 0.23.0 fix implements this distinction for the CODEX_HOME redirection path (CheckPoint Research).

For enterprise defenders the strategic implication is inventory: developer workstations are now meaningfully part of the AI attack surface, not just the AI service attack surface, and software-composition tracking needs to cover the agentic CLIs developers have installed alongside the LLM APIs those CLIs connect to (RAXE assessment).

References

1. NVD, CVE-2025-61260, https://nvd.nist.gov/vuln/detail/CVE-2025-61260 (accessed 2026-04-20; record published 2026-04-14, lastModified 2026-04-17, status: Awaiting Analysis).
2. CheckPoint Research, OpenAI Codex CLI Command Injection Vulnerability, https://research.checkpoint.com/2025/openai-codex-cli-command-injection-vulnerability/ (accessed 2026-04-20; article published 2025-12-01).
3. npm registry, @openai/codex 0.23.0 manifest, https://registry.npmjs.org/@openai/codex/0.23.0 (publish time 2025-08-20T06:07:34.871Z, verified 2026-04-20).
4. FIRST.org EPSS, CVE-2025-61260, https://api.first.org/data/v1/epss?cve=CVE-2025-61260 (score 0.00103, percentile 28.2, 2026-04-20).