A Prompt Hidden in a GitHub Issue Gave Researchers a Path to Publishing OpenAI's Codex CLI on npm

Researchers at security company Depi say a single crafted GitHub issue was enough to start a chain of exploits that could have ended with a malicious release of OpenAI’s official Codex CLI package on npm. Depi published the full write-up on November 11, 2026, with OpenAI’s permission. The researchers say they reported the chain through Bugcrowd with a full proof of concept, and that OpenAI “deployed a fix right away.”

The work comes from Pierre Martin (Worty) and Garance de la Brosse (Madder), who describe themselves as founding hackers at Depi. Their target was @openai/codex, which Depi says is downloaded millions of times a month. The chain was demonstrated against a test environment; the write-up does not describe any malicious release reaching users.

An issue labeler that trusted strangers

The entry point was an Issue Labeler workflow in the openai/codex repository. It used openai/codex-action, pinned to a specific commit of v1.7, to read newly opened issues and suggest labels. The workflow ran whenever an issue was opened or received a codex-label label, and it was configured with allow-users: "*". That meant anyone able to open an issue could have its title and body processed by the Codex agent.

Both fields were pasted straight into the agent’s prompt. Depi found that closing the real prompt structure and presenting a new set of “system” instructions could make the model treat the issue body as orders rather than data. The injected framing cast Codex as a QA engineer told to run diagnostic commands from the issue, with the follow-on script compressed and encoded so the model ran it without first recognizing what it did.

Reading tokens out of the runner’s memory

Code execution inside the agent was not yet a breakout. Codex was running in its workspace-write sandbox, which according to Depi blocks network calls such as connect, blocks ptrace, hides other processes, and allows writes only to the working directory and /tmp/.

The gap was in /tmp/. GitHub’s runner uses two .NET processes, Runner.Listener and Runner.Worker. When they start, the .NET runtime (CoreCLR) creates debug pipes there. On Linux those pipes can be opened like ordinary files, so the sandbox’s ban on sockets did not stop a process that already had a shell from talking to them. Depi says the handshake is unauthenticated: anyone who can open the pipes gets debug access.

From that channel, the researchers describe reading process memory until they recovered ACTIONS_RUNTIME_TOKEN and GITHUB_TOKEN from the worker that held the job-scoped secrets. With no outbound network in the sandbox, they say the tokens were printed into the workflow logs in long chunks, and the injected prompt kept the job alive because the cache token stayed valid only while the workflow was running.

From stolen tokens to a poisoned cache

Those tokens were then used from an attacker-controlled repository against OpenAI’s GitHub Actions cache. Depi says GitHub cache content is a tar archive of absolute paths that is extracted without integrity checks. With a matching cache key, which they say can be computed without secrets, an attacker can plant a file into a later job that trusts that cache.

The interesting follow-on workflow was rust-ci.yml, which Depi says has broad write permissions and recovers Rust binaries from the cache before running Python tests. A planted malicious test could then abuse those permissions. In the write-up, the researchers describe using a separate GitHub quirk shared by Adnan Khan: a workflow that asks for OpenID Connect when a release is deleted. By creating a rogue release that a maintainer would delete, they say they could obtain a signed JWT that npm trusts for publishing.

With that JWT and write permissions, Depi concludes, an attacker could have asked GitHub for credentials to publish a malicious version of Codex on npm. “A malicious version of Codex CLI doesn’t need to find a way to run,” the write-up says. “Running is the feature.”

Fixed, but the lesson is about auto-update

Depi says OpenAI fixed the core bug that enabled the chain, so there is nothing for end users to patch on their machines. The researchers say Bugcrowd triage was quick and that OpenAI awarded an initial bounty of $1,000, with the report still under further review against a policy that lists rewards of up to $100,000 for critical findings.

The defensive takeaway is about speed versus trust. Security advice usually tells developers to update tooling immediately; for an agent that auto-updates and then executes code with developer credentials, Depi argues for a short cooldown so someone else can be first to run a brand-new release. The chain did not start with a memory-corruption bug. It started with a string of text in a workflow that trusted issue content.