RCE flaw in OpenAI’s Codex CLI highlights new risks to dev environments

In a new example of how AI tools expand the attack surface of development machines, researchers found a serious remote code execution flaw in OpenAI’s Codex CLI, one of the most popular LLM-powered coding agents.

“This vulnerability enables silent, repeatable remote code execution in any environment where developers run codex against a repository,” researchers from security firm CheckPoint, who found the flaw, said in their report. “By abusing project-local config loading, an attacker who can land a commit or PR can turn an otherwise innocent repo into a persistent backdoor that triggers whenever a developer runs codex, with no additional prompts or approvals.”

The vulnerability was reported to OpenAI and was fixed in Codex CLI version 0.23.0 by preventing .env files from silently redirecting the CODEX_HOME environment variable to attacker-controlled locations.

Tricking Codex to execute rogue MCP entries

Like all AI-assisted coding agents, Codex has some powerful privileges since it needs to be able to read, edit and run code directly from the terminal. In the default mode, the tool can perform tasks without approval within the working directory, but users can change it to either read only or full access.

Allowing the tool to execute commands and modify files in a controlled directory might not seem too risky at first glance, but the CheckPoint researchers found a creative way to abuse it.

First, like many AI agents, Codex supports the Model Context Protocol (MCP). Developed by AI company Anthropic, MCP has become the de facto industry method of linking LLMs to external data sources and applications. In other words, it’s a building block for creating autonomous AI agents that can automatically discover and use third-party tools.

Codex CLI loads and executes configured MCP servers at startup by checking for mcp_servers entries in its .codex/config.toml configuration file. If an attacker can modify this file, they can force Codex to execute malicious commands by adding a rogue MCP server entry to the list.

Codex will search for its config file in its home directory, and this directory is defined through an environment variable called CODEX_HOME. The researchers wondered if this variable could be overridden when parsing .env files that are included in a repository, since including such files with projects is not unusual.

The researchers found that a repository could have an .env file that sets CODEX_HOME to a path of the form ./.codex, essentially the folder .codex from within the current working directory – the repository directory itself. Furthermore, if the repository then has a config.toml file in the .codex directory, the Codex agent will treat it as its own config file and will parse the mcp_servers entries.

“Because the behavior binds trust to the presence of the MCP entry under the resolved CODEX_HOME rather than to the contents of the entry, an initially innocuous config can be swapped for a malicious one post-approval or post-merge, creating a stealthy, reproducible supply-chain backdoor that triggers on normal developer workflows,” the researchers said.

The researchers demonstrated this attack by replacing benign commands in MCP server entries with commands to create files or open a reverse shell on the machine. These commands were executed without user approval in default configuration.

Multiple attack vectors

For this flaw to be exploited, the victim needs to clone the repository and run Codex on it and an attacker needs to have commit access to the repo or have their malicious pull request accepted.

“Compromised templates, starter repos, or popular open-source projects can weaponize many downstream consumers with a single commit,” the researchers warned.

Furthermore, CI tools or build agents automatically run Codex on checked-out code, the compromise could propagate from a developer workstation into build artifacts and downstream deployments of the code.

Development machines often contain API tokens for various cloud services, as well as SSH keys and proprietary source code, all of which can be exfiltrated and abused to move laterally to additional assets.

“This breaks the CLI’s expected security boundary: project-supplied files become trusted execution material, and that implicit trust can be exploited with minimal effort and no user interaction beyond standard development workflow,” the researchers found.

While Codex CLI now blocks project-local redirection of the CODEX_HOME environment variable, the incident highlights that such security oversights can exist even in agents created by the leading AI companies. Last week, researchers warned about a flaw that allows instructions from a cloned repository to escape the confines of the current workspace in Google’s new AI-powered Antigravity IDE tool. Earlier this month another team of researchers showed how rogue MCP servers can take over Cursor’s built-in browser and potentially fully compromise the developer machine.

Organizations that allow their developers to work with AI coding agents and IDE tools should have policies in place regarding the level of automation these tools are configured with, as they can easily become powerful backdoors in case of vulnerabilities or misconfigurations. Security experts have repeatedly cautioned against using the fully automated modes that don’t require human review and approval of the execution steps.