Finding Codex Deployments After the Sandbox Escape Disclosures
Finding Codex Deployments After the Sandbox Escape Disclosures On September 21, 2026, security media reported that researchers had disclosed sandbox escape issues in OpenAI's Codex tooling. The flaws were reported to O
Finding Codex Deployments After the Sandbox Escape Disclosures
On September 21, 2026, security media reported that researchers had disclosed sandbox escape issues in OpenAI's Codex tooling. The flaws were reported to OpenAI on August 12, 2026, and fixes shipped in Codex CLI 0.149.0 (released August 21, 2026) and Codex Desktop 26.818.21641 and later. The current CLI release at the time of reporting was 0.155.1. For defenders, the practical question is not whether the patch exists, but how many Codex installations are reachable inside their own estate.
What the disclosure actually covers
Two distinct issues were described. The first sits in the Codex CLI patching utility. Codex normally restricts file writes to the current workspace. Crafted patch content could widen that write scope, and under specific conditions symbolic links could redirect writes into a user directory or other sensitive locations, reportedly without an additional authorization prompt.
The second involves the Node.js tool that ships with the Codex desktop edition. Trusted and untrusted scripts share part of the process memory space, which the researchers describe as an opening for untrusted code to read authentication tokens from that shared region, forge requests, and hand them to external native programs. Those programs can launch applications, connect to local Unix sockets, or modify global configuration files. The report states this path triggers even under strict read-only mode and requires no manual approval, only a repository containing malicious content.
Both descriptions come from a single security news write-up summarising researcher findings. The underlying technical breakdown was not independently reproduced here, and no CVE identifiers were published in the source material. Treat the mechanism as reported rather than verified.
Why asset identification comes first
A sandbox escape matters most where the agent runs with access to something worth reaching: source repositories, signing material, cloud credentials, or developer workstations that bridge into production networks. Codex is a developer tool, so its footprint tends to sit on engineering laptops and build hosts rather than on internet-facing servers. That makes it invisible to conventional external scanning and easy to miss in software inventories.
This is where an internet-wide asset search engine helps as a discovery aid rather than a verdict. ZoomEye indexes internet-reachable services and devices. It can surface hosts that advertise Codex-related identifiers, but it cannot see a laptop behind a corporate firewall, and it cannot confirm that any indexed host is vulnerable. The distinction matters: an indexed instance is an observation, not a compromise.
Running the query
The relevant search uses the application identifier:
app="Codex"
Executed through the AutoPR ZoomEye integration on September 21, 2026, this returned 164 matching instances globally. A broader body-text search for codex returned 172, and a title search for Codex returned 6,146. The wider title count is the least specific of the three and should be treated with caution, since the word appears in unrelated product names and page titles.
The narrower app="Codex" result is the more defensible starting point because it relies on application fingerprinting rather than free-text matching. Even so, 164 is a count of indexed internet-facing matches, not a count of affected organisations. Some will be developer-facing services deliberately published, some will be misconfigured, and some may be false positives from the fingerprint.
Turning the count into an inventory task
The number is useful as a scoping input. Three steps follow naturally.
First, compare the external view against internal records. If your software inventory shows no Codex installations but the external search shows hosts in your address space, that gap is worth explaining before anything else.
Second, prioritise by exposure. A Codex instance reachable from the internet with weak authentication is a different risk class from one bound to localhost on a managed laptop. The search result alone does not tell you which is which, so pair it with your own network telemetry.
Third, verify versions. The fixes are version-specific: CLI 0.149.0 and Desktop 26.818.21641. An installation older than those thresholds is the concrete remediation target, and version data comes from your own endpoint tooling, not from an external index.
Limitations to keep in view
The 164 figure reflects what ZoomEye had indexed at one point in time. Index coverage varies by region, port and protocol, and services can appear or disappear between scans. A low count is not proof of safety, and a high count is not proof of exposure to this specific flaw. The reported attack path also depends on a user opening a repository containing malicious content, which is a behavioural precondition that no external scan can evaluate.
References
- SecurityOnline.info, "OpenAI Codex Sandbox Escape Vulnerabilities Disclosed," September 21, 2026: https://securityonline.info/openai-codex-sandbox-escape/
- ZoomEye search interface: https://www.zoomeye.ai/
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.