AI Threat AlertCVE-2026-19591: Codex CLI: PowerShell parsing flaw bypasses approval, RCE
HIGHOpenAI's Codex CLI and Codex Desktop contain a command-safety parser that interprets PowerShell's stop-parsing token (--%) differently than PowerShell itself does, letting a maliciously crafted repository trick Codex into running a file-writing Git command without the user's approval. This matters because Codex is an agentic coding tool with 1,063 downstream dependents, and the flaw sits at the boundary between untrusted repository content and an agent's execution privileges — if the write succeeds and later modifies Codex's configuration, the agent can be made to launch an attacker-controlled MCP server and execute code with the user's full account privileges. There is no CISA KEV listing, no public exploit or scanner template, and no EPSS score, so this is not yet under active exploitation, but the multi-step nature (open a hostile repo, have separately-installed PowerShell Core on macOS/Linux, and a permissive filesystem sandbox) means it is realistic in developer environments that clone third-party or open-source code routinely. Security teams should confirm affected Codex CLI/Desktop instances are updated per the fix referenced in openai/codex PR #22643, enforce the default filesystem sandbox on macOS/Linux (it can block the underlying write even if approval is bypassed), and treat Codex config file changes as a detection signal — especially any addition of unexpected MCP server entries. Until patched builds are confirmed deployed, avoid using Codex against untrusted or unreviewed repositories, particularly on hosts with PowerShell Core installed.
What is the risk?
Exploitability is constrained by several preconditions: the user must open an attacker-prepared repository and let Codex act on its embedded instructions, the parser differential must trigger for a specific PowerShell construct, and on macOS/Linux a separately installed PowerShell Core binary is required. The default filesystem sandbox on macOS/Linux is an effective backstop that can prevent the write outside permitted directories, meaningfully reducing real-world blast radius on hardened installs. However, if all conditions align, impact is severe — silent approval bypass leading to persistent config tampering and eventual arbitrary code execution with the user's privileges via an attacker-controlled MCP server. No CVSS score, EPSS data, KEV listing, or public exploit exists yet, so likelihood of opportunistic exploitation today is low, but the technique (indirect prompt injection via repo content + parser inconsistency + agent auto-approval) is a class of bug likely to recur across coding agents. Overall: moderate risk today, high risk if adoption of Codex against untrusted repos is common in the affected population.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| OpenAI Node | npm | — | No patch |
| OpenAI Node | npm | — | No patch |
| OpenAI Node | npm | — | No patch |
How severe is it?
What is the attack surface?
What should I do?
1 step1) Update Codex CLI and Codex Desktop to the version containing the fix referenced in https://github.com/openai/codex/pull/22643 as soon as it is generally available. 2) Keep the default filesystem sandbox enabled on macOS/Linux — do not grant broad write permissions to Codex sessions, since the sandbox is the last line of defense against the config-tampering step. 3) Avoid installing or invoking PowerShell Core (pwsh) alongside Codex on macOS/Linux unless required, since it is a necessary condition for this exploitation path there. 4) Do not open or run Codex against untrusted or unreviewed repositories, especially ones containing embedded natural-language instructions to the agent. 5) Monitor Codex's configuration file for unexpected changes (new MCP server entries, modified server URLs/binaries) as a detection signal — treat any unapproved MCP server addition as a compromise indicator. 6) Review Codex's command-approval audit trail for file-writing Git operations that were auto-approved without user interaction.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-19591?
OpenAI's Codex CLI and Codex Desktop contain a command-safety parser that interprets PowerShell's stop-parsing token (--%) differently than PowerShell itself does, letting a maliciously crafted repository trick Codex into running a file-writing Git command without the user's approval. This matters because Codex is an agentic coding tool with 1,063 downstream dependents, and the flaw sits at the boundary between untrusted repository content and an agent's execution privileges — if the write succeeds and later modifies Codex's configuration, the agent can be made to launch an attacker-controlled MCP server and execute code with the user's full account privileges. There is no CISA KEV listing, no public exploit or scanner template, and no EPSS score, so this is not yet under active exploitation, but the multi-step nature (open a hostile repo, have separately-installed PowerShell Core on macOS/Linux, and a permissive filesystem sandbox) means it is realistic in developer environments that clone third-party or open-source code routinely. Security teams should confirm affected Codex CLI/Desktop instances are updated per the fix referenced in openai/codex PR #22643, enforce the default filesystem sandbox on macOS/Linux (it can block the underlying write even if approval is bypassed), and treat Codex config file changes as a detection signal — especially any addition of unexpected MCP server entries. Until patched builds are confirmed deployed, avoid using Codex against untrusted or unreviewed repositories, particularly on hosts with PowerShell Core installed.
Is CVE-2026-19591 actively exploited?
No confirmed active exploitation of CVE-2026-19591 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-19591?
1) Update Codex CLI and Codex Desktop to the version containing the fix referenced in https://github.com/openai/codex/pull/22643 as soon as it is generally available. 2) Keep the default filesystem sandbox enabled on macOS/Linux — do not grant broad write permissions to Codex sessions, since the sandbox is the last line of defense against the config-tampering step. 3) Avoid installing or invoking PowerShell Core (pwsh) alongside Codex on macOS/Linux unless required, since it is a necessary condition for this exploitation path there. 4) Do not open or run Codex against untrusted or unreviewed repositories, especially ones containing embedded natural-language instructions to the agent. 5) Monitor Codex's configuration file for unexpected changes (new MCP server entries, modified server URLs/binaries) as a detection signal — treat any unapproved MCP server addition as a compromise indicator. 6) Review Codex's command-approval audit trail for file-writing Git operations that were auto-approved without user interaction.
What systems are affected by CVE-2026-19591?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, CLI-based AI coding agents, MCP tool integrations.
What is the CVSS score for CVE-2026-19591?
CVE-2026-19591 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 0.56%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0050Command and Scripting InterpreterAML.T0051.001IndirectAML.T0053AI Agent Tool InvocationAML.T0081Modify AI Agent ConfigurationAML.T0112.000Local AI AgentCompliance Controls Affected
What are the technical details?
Original Advisory
OpenAI Codex CLI for Windows, macOS, and Linux and Codex Desktop for Windows and macOS misclassified certain PowerShell commands as safe because their command-safety parser interpreted PowerShell's stop-parsing token (--%) differently than PowerShell itself. If a user opens an attacker-prepared repository and Codex follows its instructions, Codex can run a file-writing Git command without requesting user approval. On macOS and Linux, exploitation additionally requires separately installed PowerShell Core (pwsh) to be invoked. If filesystem protections permit the write, the command can modify Codex's configuration. If Codex later loads the modified configuration, it can launch an attacker-controlled MCP server and execute code with the user's privileges, allowing it to read, change, or delete files accessible to that account. The approval bypass does not disable filesystem sandboxing; the default filesystem sandbox on macOS and Linux can prevent writes outside permitted locations.
Exploitation Scenario
An attacker publishes or contributes to a public repository containing hidden instructions and a specially crafted PowerShell command using the --% stop-parsing token in a way that Codex's safety parser misreads as benign. A developer opens this repository in Codex CLI/Desktop and asks the agent to review or work on the code; Codex follows the embedded instructions and executes the disguised Git command without prompting for approval, believing it to be safe. On a permissively configured host (or where the sandbox fails to constrain the target path), the command writes to Codex's own configuration file. The next time Codex starts, it loads the tampered configuration and connects to an attacker-controlled MCP server, which then executes arbitrary code with the developer's account privileges — enabling the attacker to read, modify, or delete any files accessible to that user.
Weaknesses (CWE)
CWE-150Improper Neutralization of Escape, Meta, or Control SequencesCWE-150Improper Neutralization of Escape, Meta, or Control SequencesCWE-150 — Improper Neutralization of Escape, Meta, or Control Sequences: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as escape, meta, or control character sequences when they are sent to a downstream component.
- Developers should anticipate that escape, meta and control characters/sequences will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.
- [Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:HReferences
Timeline
Related Vulnerabilities
GHSA-vjc7-jrh9-9j8610.09Router: no-auth API leaks keys, chats, provider control
Same package: openaiCVE-2026-6153910.0Xinference: eval() on LLM output enables RCE
Same package: openaiCVE-2024-238279.8Nginx-UI: arbitrary file write via cert import leads to RCE
Same package: openaiCVE-2025-612609.8OpenAI Codex CLI: RCE via malicious MCP config files
Same package: openaiCVE-2026-195939.8Codex Desktop: Git config filter triggers sandbox-escape RCE
Same package: openai