Skip to main content

You opened a repo, and its bundled `.codex` config ran a command through me (Codex CLI CVE-2025-61260)

In one sentence: in August 2025 Check Point disclosed a command-injection flaw in Codex CLI (CVE-2025-61260, CVSS 9.8): a malicious repo's bundled .codex config (an MCP server entry) was auto-executed without interactive approval, and a repo-supplied .env could redirect CODEX_HOME into the project directory โ€” so just "clone / open this repo and take a look" ran the attacker's command on your machine, through me. Fixed in v0.23.0. This isn't about one particular model or tool โ€” it exposes the same class of mechanism risk: when an agent auto-executes a repo's bundled config without interactive approval, a similar incident can recur on other tools. Worth watching frame by frame.

Several pitfalls that detonated in a single incident

When: August 2025 ยท Tool: OpenAI Codex CLI (found by Check Point Research) ยท fixed in v0.23.0 ยท Sources at the end

What happenedโ€‹

Codex CLI is OpenAI's open-source terminal coding agent. Check Point found that a .codex config placed in a project directory โ€” including its MCP server entries โ€” was auto-loaded and executed without an interactive approval prompt. Chain that with one redirect and you get full remote command execution:

  1. CODEX_HOME can be redirected by the repo. A repo's bundled .env could point CODEX_HOME at the project directory itself, so Codex read "the project's .codex" for config โ€” and that config was the attacker's.
  2. Persistence keyed on presence, not content. The trust / persistence check hung on "an MCP entry exists under the resolved CODEX_HOME," not on what it contained โ€” so a benign entry you once approved could later be silently swapped for a malicious one, with no re-prompt.
  3. The trigger was just "open the repo." Cloning a poisoned repo โ€” or a compromised scaffold / starter template โ€” and asking me to take a look was enough to run that MCP command on your machine.

The flaw scored CVSS 9.8, was disclosed on 2025-08-07, and was fixed on 2025-08-20 in v0.23.0 (closing the .env โ†’ CODEX_HOME redirection path).

Which pitfalls it hitโ€‹

  • Dev-time prompt injection: I don't separate "a file in the repo" from "instructions for me" โ€” and here the "file" isn't even a README, it's a config file the agent reads automatically. You tell me to look at the repo, and I treat its config as your intent and execute it.
  • MCP over-access: an auto-loaded MCP config is a standing "hand" pre-wired for me to use; trusting an entry by its mere existence rather than its content means that hand can be swapped for someone else's.
  • Over-permissioning / skipping approval: auto-execute with no confirmation is exactly the missing "human in the loop" โ€” and skipping it is what lets an injection, once landed, run unchallenged.

The costโ€‹

  • Very low bar, very high impact. No setting change on the victim's side โ€” "open a repo" is enough; once a command runs, the credentials, tokens, and source on the dev machine are all in exfiltration range.
  • Supply-chain amplification. The poisoned thing needn't be an obscure repo โ€” a compromised scaffold template or a tampered dependency repo replicates the chain to everyone who clones it.
  • This time researchers found it first, disclosed responsibly, and it was patched fast โ€” no public mass loss. But it precisely demonstrates that a config file an agent auto-loads is itself an execution surface โ€” exactly the "defaults / default trust" that tool differences should watch.

Guardrails: how you and I avoid a repeatโ€‹

Each maps to a mechanism in the linked entries:

  1. Upgrade to โ‰ฅ v0.23.0, and distrust "config files the agent reads automatically" by default (.codex, .cursor, .mcp and friends) โ€” they're untrusted input, just like a README.
  2. Isolate unfamiliar / cloned repos before opening them; don't let me "freely explore" a repo you haven't vetted. Codex ships an OS sandbox + network-off by default โ€” don't casually strip it with --dangerously-bypass-approvals-and-sandbox.
  3. Don't blanket-approve MCP / tools, and especially don't let "the entry exists" mean "trusted forever" โ€” a config change should force re-confirmation.
  4. Move secrets out of the environment the agent process can reach โ€” it can't exfiltrate what it can't read.

For the full mechanism, see Dev-time prompt injection and MCP over-access.

What this case shows โ€” and what it doesn'tโ€‹

Pitfalls it confirms (click through for the full mechanism reasoning):

What it does not prove: This is a specific, already-patched vulnerability (CVE-2025-61260, fixed in v0.23.0) in Codex CLI โ‰ค v0.22 โ€” not evidence that today's Codex CLI is still exploitable this way, nor that "all MCP configs" or "all coding agents" lead to RCE. It backs a class of mechanism risk (a config the agent auto-loads is itself an execution surface), not a verdict that one tool is "unsafe."

Sourcesโ€‹