Description

OpenAI Codex Desktop for Windows and macOS automatically inspected Git metadata and working-tree status when a user opened a workspace. If the workspace contains a repository with preserved attacker-controlled .git/config, the attr.tree setting and a configured clean or process filter can cause Git to run an attacker-controlled program. The program runs outside Codex's command sandbox with the signed-in user's privileges, without a workspace-trust prompt, command approval, or interaction with a model. The attacker can read, modify, or delete files and access credentials available to that user. Exploitation requires Git to be available on PATH and the user to open the attacker-prepared repository with its local Git configuration intact. An ordinary Git clone does not copy the source repository's .git/config and is not sufficient by itself.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-01T18:17:40.480Z",
  "pubdate": "2026-09-01T18:17:40.480Z",
  "executiveSummary": "OpenAI Codex Desktop for Windows and macOS is susceptible to a critical Arbitrary Code Execution (ACE) vulnerability stemming from the automatic inspection of untrusted Git metadata.\nThe vulnerability allows for the execution of arbitrary commands with the privileges of the signed-in user whenever a workspace containing a malicious '.git/config' file is opened.\nBecause the execution bypasses workspace-trust prompts and command sandboxing, an attacker can gain full access to the user's filesystem, including the ability to read, modify, or delete sensitive data and exfiltrate user credentials.\nThe impact is significant, as the exploit executes silently without requiring user interaction beyond opening the malicious repository.\nExploitation requires the victim to open a specially crafted repository where the '.git/config' file is preserved, meaning the vulnerability relies on the local configuration being maintained during repository acquisition.\nThis represents a severe security risk, as the application assumes that all Git metadata within a workspace is implicitly trusted during the initial workspace indexing phase.",
  "technicalDetails": "The root cause of this vulnerability lies in the automatic, non-sandboxed inspection of Git metadata performed by OpenAI Codex Desktop upon opening a workspace. When the application initializes a workspace, it automatically scans the directory for Git repositories to determine status and metadata.\nThe vulnerability is triggered when the application parses a malicious '.git/config' file contained within the workspace. By manipulating the 'attr.tree' setting or configuring a malicious 'clean' or 'process' filter, an attacker can force Git to execute arbitrary code.\nSpecifically, Git's filter capabilities allow for the invocation of external binaries during standard operations. Because OpenAI Codex invokes Git functions as part of its workspace inspection process, it inadvertently executes these attacker-defined filters.\nCrucially, this execution occurs outside the defined security sandbox of the OpenAI Codex application. The payload is executed directly with the privileges of the OS user currently running the desktop application, effectively inheriting the user's session token, environment variables, and filesystem permissions.\nThe attack flow is as follows: 1) The attacker prepares a repository containing a malicious '.git/config' file that defines a harmful 'process' or 'clean' filter. 2) The repository is delivered to the victim. 3) The victim opens the workspace in OpenAI Codex. 4) Upon initialization, the application invokes Git to inspect repository status. 5) Git reads the configuration and executes the malicious payload specified in the filter. 6) The payload executes under the victim's user context, providing the attacker with full access to the machine.\nThis mechanism bypasses existing security controls, such as workspace-trust prompts or model-based command approval, as the execution is a direct result of the IDE's internal background processes rather than an explicit user-initiated command.\nWhile an ordinary Git clone does not preserve internal '.git/config' files, the vulnerability remains high-risk for users who manually copy repositories or use tools that persist Git configuration state. The lack of validation on the integrity of Git metadata before processing is the fundamental flaw that enables this post-exploitation scenario."
}