CVE-2026-19592: OpenAI Node git core.fsmonitor hook

CISO Take

OpenAI's Codex CLI and Desktop apps automatically run git commands to collect repository metadata, and if a repo's preserved .git/config sets core.fsmonitor to point at an attacker-controlled helper, Git executes that helper the moment Codex touches the repo — completely outside Codex's command sandbox and without any approval prompt. Because Codex sits in front of 1,063 downstream dependents and is used daily by developers who routinely pull down third-party code, this is a credible vector for any team that lets engineers open unvetted repositories with an AI coding agent. There is no CISA KEV listing, no public exploit, and no EPSS score yet, but the technique defeats the exact sandbox boundary Codex relies on for safety, so exploitation likelihood should be judged on novelty of the bypass rather than current telemetry. The practical constraint working in defenders' favor is that an ordinary git clone strips the malicious .git/config, so an attacker must deliver the repo another way — a zip download, a shared drive, a CI artifact — with the poisoned config intact. Patch to the fixed Codex CLI/Desktop release as soon as it's available, and in the meantime block Codex from opening repositories not obtained via a fresh git clone and audit .git/config for unexpected core.fsmonitor entries before letting an AI agent touch an unfamiliar codebase.

Sources:NVDATLASgithub.com/openai/codex

What is the risk?

Moderate-to-high risk despite the absence of KEV listing or public exploit code. The flaw breaks the core security promise of Codex's command sandbox — arbitrary code execution with the user's full privileges, triggered without any approval prompt. Likelihood of opportunistic mass exploitation is limited because a standard git clone does not preserve the malicious .git/config, so the attacker needs a delivery mechanism that keeps the local config intact (archive download, shared filesystem copy, internal repo mirror, CI artifact). This narrows the threat mostly to targeted social-engineering scenarios (e.g., 'clone this troubleshooting repo I zipped for you') rather than drive-by compromise, but the payoff for a successful attacker — full sandbox escape with silent, unattended code execution — is severe, and developer endpoints running Codex often have elevated access to source code, credentials, and CI/CD systems.

How does the attack unfold?

Delivery of poisoned repository

Attacker crafts a repository with a preserved .git/config that sets core.fsmonitor to a malicious helper and distributes it via a method that keeps the local config intact (zip, tarball, shared copy) rather than a normal git clone.

AML.T0011

Victim opens repository in Codex

The victim extracts or copies the repository and opens or uses it within Codex CLI or Codex Desktop.

AML.T0011

Sandbox-bypassing execution

Codex automatically collects Git repository metadata, causing Git to invoke the attacker-controlled fsmonitor helper outside Codex's command sandbox and without any approval prompt.

AML.T0050

Impact

The attacker's code runs with the user's full privileges, allowing it to read, modify, or delete files and access other resources available to the user's account.

AML.T0037

Delivery of poisoned repository

Attacker crafts a repository with a preserved .git/config that sets core.fsmonitor to a malicious helper and distributes it via a method that keeps the local config intact (zip, tarball, shared copy) rather than a normal git clone.

AML.T0011

Victim opens repository in Codex

The victim extracts or copies the repository and opens or uses it within Codex CLI or Codex Desktop.

AML.T0011

Sandbox-bypassing execution

Codex automatically collects Git repository metadata, causing Git to invoke the attacker-controlled fsmonitor helper outside Codex's command sandbox and without any approval prompt.

AML.T0050

Impact

The attacker's code runs with the user's full privileges, allowing it to read, modify, or delete files and access other resources available to the user's account.

AML.T0037

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
OpenAI Node	npm	—	No patch
11.2K1.8K dependentsPushed today56% patched~139d to patchFull package profile →
OpenAI Node	npm	—	No patch
11.2K1.8K dependentsPushed today56% patched~139d to patchFull package profile →
OpenAI Node	npm	—	No patch
11.2K1.8K dependentsPushed today56% patched~139d to patchFull package profile →

How severe is it?

CVSS 3.1

7.3 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 5% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○CISA SSVC: Public PoC

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AVLocal

ACLow

PRLow

UIRequired

SUnchanged

CHigh

IHigh

AHigh

What should I do?

1 step

1) Patch Codex CLI and Codex Desktop to the fixed release as soon as OpenAI publishes one (track https://github.com/openai/codex/pull/22652 for the merged fix). 2) Until patched, avoid opening or 'using' repositories in Codex that were obtained via zip download, tarball extraction, shared drive copy, or any method other than a direct git clone from a trusted remote. 3) Before pointing Codex at an unfamiliar repo, inspect .git/config for an unexpected core.fsmonitor setting pointing to an executable/script, and strip or neutralize it. 4) Set a global Git safeguard (e.g., git config --global core.fsmonitor false or restrict which fsmonitor helpers are trusted) on developer endpoints that run Codex. 5) For detection, monitor for fsmonitor-hook or unexpected child-process execution spawned by git status/git diff invocations originating from Codex CLI/Desktop process trees, especially processes with no corresponding user-initiated git command.

What does CISA's SSVC say?

DecisionAttend

Exploitationpoc

AutomatableNo

Technical Impacttotal

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Code ExecutionSupply ChainAgentAML.T0011- User Execution AML.T0050- Command and Scripting Interpreter AML.T0053- AI Agent Tool Invocation

Which compliance frameworks are affected?

This CVE is relevant to:

NIST AI RMF

MANAGE 2.3-Procedures are followed to respond to and recover from AI system incidents involving third-party components

OWASP LLM Top 10

LLM06-Excessive Agency

Frequently Asked Questions

What is CVE-2026-19592?

OpenAI's Codex CLI and Desktop apps automatically run git commands to collect repository metadata, and if a repo's preserved .git/config sets core.fsmonitor to point at an attacker-controlled helper, Git executes that helper the moment Codex touches the repo — completely outside Codex's command sandbox and without any approval prompt. Because Codex sits in front of 1,063 downstream dependents and is used daily by developers who routinely pull down third-party code, this is a credible vector for any team that lets engineers open unvetted repositories with an AI coding agent. There is no CISA KEV listing, no public exploit, and no EPSS score yet, but the technique defeats the exact sandbox boundary Codex relies on for safety, so exploitation likelihood should be judged on novelty of the bypass rather than current telemetry. The practical constraint working in defenders' favor is that an ordinary git clone strips the malicious .git/config, so an attacker must deliver the repo another way — a zip download, a shared drive, a CI artifact — with the poisoned config intact. Patch to the fixed Codex CLI/Desktop release as soon as it's available, and in the meantime block Codex from opening repositories not obtained via a fresh git clone and audit .git/config for unexpected core.fsmonitor entries before letting an AI agent touch an unfamiliar codebase.

Is CVE-2026-19592 actively exploited?

No confirmed active exploitation of CVE-2026-19592 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-19592?

1) Patch Codex CLI and Codex Desktop to the fixed release as soon as OpenAI publishes one (track https://github.com/openai/codex/pull/22652 for the merged fix). 2) Until patched, avoid opening or 'using' repositories in Codex that were obtained via zip download, tarball extraction, shared drive copy, or any method other than a direct `git clone` from a trusted remote. 3) Before pointing Codex at an unfamiliar repo, inspect `.git/config` for an unexpected `core.fsmonitor` setting pointing to an executable/script, and strip or neutralize it. 4) Set a global Git safeguard (e.g., `git config --global core.fsmonitor false` or restrict which fsmonitor helpers are trusted) on developer endpoints that run Codex. 5) For detection, monitor for fsmonitor-hook or unexpected child-process execution spawned by `git status`/`git diff` invocations originating from Codex CLI/Desktop process trees, especially processes with no corresponding user-initiated git command.

What systems are affected by CVE-2026-19592?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI coding assistants / developer tooling.

What is the CVSS score for CVE-2026-19592?

CVE-2026-19592 has a CVSS v3.1 base score of 7.3 (HIGH). The EPSS exploitation probability is 0.16%.

What is the AI security impact?

Affected AI Architectures

agent frameworksAI coding assistants / developer tooling

MITRE ATLAS Techniques

AML.T0011User Execution

AML.T0050Command and Scripting Interpreter

AML.T0053AI Agent Tool Invocation

Compliance Controls Affected

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

OpenAI Codex CLI for Windows, macOS, and Linux and Codex Desktop for Windows and macOS automatically collected Git repository metadata without disabling the repository-local core.fsmonitor setting. If a user opens or uses an attacker-prepared repository whose preserved .git/config sets core.fsmonitor to an attacker-controlled filesystem-monitor helper, Git can execute that helper while Codex collects repository metadata. The helper runs outside Codex's command sandbox and without a user-approval prompt, allowing attacker-controlled code to run with the user's privileges. The code can read, change, or delete the user's files and access other resources available to the user's account. An ordinary Git clone does not preserve the source repository's local .git/config; exploitation requires a repository delivered or copied with that configuration intact.

Exploitation Scenario

An attacker prepares a git repository, sets `core.fsmonitor` in its `.git/config` to a malicious script or binary they control, and distributes the repository in a way that preserves that local config file — for example as a zip archive labeled 'reproduction repo for bug X' or a tarball shared via a support ticket, Slack channel, or file-sharing link (a normal `git clone` would strip this config, so the attacker deliberately avoids that path). The victim downloads the archive, extracts it, and opens or 'uses' it inside Codex CLI or Codex Desktop — for instance asking Codex to review or explain the code. Codex automatically collects Git repository metadata as part of building context, which invokes `git status` or similar, causing Git to launch the configured fsmonitor helper. That helper executes with the victim's full user privileges, entirely outside Codex's command sandbox and without any approval prompt, giving the attacker the ability to read, modify, or delete the victim's files and access any resource available to that user account — including source code, tokens, and CI/CD credentials on the developer's machine.

Weaknesses (CWE)

CWE-15External Control of System or Configuration Setting CWE-15External Control of System or Configuration Setting

CWE-15 — External Control of System or Configuration Setting: One or more system settings or configuration elements can be externally controlled by a user.

[Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
[Implementation, Architecture and Design] Because setting manipulation covers a diverse set of functions, any attempt at illustrating it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.

Source: MITRE CWE corpus.