Researchers at Depi Security have shown how a single malicious GitHub issue could have started a chain ending in control over publishing for OpenAI’s official Codex CLI package on npm. OpenAI fixed the problem quickly but has so far paid an initial bounty of just $1,000, a figure that raises awkward questions about how AI vendors value supply-chain findings.
What happened
On 11 November 2026, Depi Security published a detailed write-up of a vulnerability chain in the GitHub Actions automation behind OpenAI’s open source Codex repository. The research was carried out by Pierre Martin (Worty) and Garance de la Brosse (Madder), who describe themselves as founding hackers at the company. Their conclusion: an outside attacker with nothing more than a GitHub account could, in principle, have worked their way from an ordinary issue report to the credentials needed to push a poisoned release of @openai/codex, the npm package that installs the Codex CLI on developer machines.
The team reported the chain, with a full proof of concept, through OpenAI’s bug bounty programme on Bugcrowd. According to Depi, OpenAI shipped a fix promptly and acknowledged the severity, then awarded an initial $1,000 while the report remains under review. SecurityWeek, which covered the disclosure on 13 November, also reported the fix and the $1,000 payment. Neither Depi nor the coverage reports any malicious release reaching users; this was a demonstration of what was possible, not a live compromise.
The timing is notable. Earlier this month OpenAI overhauled its programme, saying the midpoints of its medium, high and critical reward ranges had more than quadrupled on average, with exceptional critical bugs eligible for up to $100,000 in base bounty and as much as $172,000 once bonuses are added, according to Help Net Security. Against that backdrop, a four-figure opening award for a credible route into a widely used package’s release pipeline looks modest.
The technical picture
The entry point was an issue-labelling workflow. When anyone opened a new issue, the workflow passed its title and body to the Codex agent and asked it to suggest labels. Because the agent received that untrusted text in the same natural-language context as its genuine instructions, and because the action was configured to accept input from any user, a carefully worded issue could steer it. Depi says it found phrasing that made the model treat the issue body as fresh instructions, and that disguising the payload helped it slip past Codex’s own guardrails.
That gave code execution, but only inside the agent’s sandbox, which blocks network access and process debugging and leaves most of the filesystem read-only. The researchers’ escape route was the runner itself. The .NET processes that drive GitHub-hosted runners leave debugging pipes in the temporary directory, and Depi found that those pipes accept an unauthenticated debug session. By reading the runner’s memory through them, the team says it recovered the job’s GitHub and Actions runtime tokens, which the sandbox had deliberately stripped from its own environment.
From there the chain moved sideways. Another workflow in the repository, with broader write permissions, restored a build cache before running tests. With a stolen token and Cacheract, researcher Adnan Khan’s cache-poisoning tool, an attacker could plant a poisoned cache entry and get their own code run in that more privileged job. Depi then combined this with a technique Khan shared to obtain an OpenID Connect token when a maintainer deleted a rogue release, which in turn could be exchanged for npm publishing rights. That final step relied on a maintainer performing a routine clean-up.

Why it matters for UK organisations
Codex CLI is an agent, not a passive library. It runs on developer laptops and build servers with access to source code and cloud credentials, and executing commands is its whole purpose, so a tampered release would simply be run. AI coding assistants of this kind are increasingly common in UK engineering teams, often installed globally from npm and left to update themselves.
This is the software supply chain risk the NCSC has been warning about for years, given a new twist. Nobody needed exotic exploitation skills to get started; the opening move was a few lines of text in a public issue, processed by an AI agent wired into CI with more trust than it deserved. Any organisation that has bolted LLM-driven triage, labelling or review onto public repositories should assume the same class of flaw could exist in its own pipelines.
Expert view
In my experience, CI/CD findings are routinely undervalued because they do not look like a classic remote code execution against a production service. Triage teams see “prompt injection in a labelling bot” and reach for a low severity before following the chain to its end. Depi’s write-up is a useful corrective: each link on its own seems minor, and the impact only becomes clear when you join them up.
To be fair to OpenAI, the $1,000 is explicitly an initial award and the report is still being assessed. The researchers praised the speed of Bugcrowd’s triage and OpenAI’s fix. If the eventual payout lands closer to the critical bracket, this becomes a reasonable story about a programme working as intended. If it does not, it sends a poor signal to the people best placed to find these bugs, at a time when AI vendors are asking researchers to take their expanded programmes seriously.
When we test build pipelines, the recurring themes are the same: workflows triggered by outsiders, shared caches nobody validates, and tokens with far more permission than the job needs.
What to do now
- Review workflows that process outside input. Find any GitHub Actions or similar jobs that feed issue, comment or pull request text from external users into an AI agent, and restrict who can trigger them. Treat that text as hostile data.
- Apply least privilege to CI tokens. Set workflow permissions to read-only by default and grant write, release or OpenID Connect rights only to the specific jobs that need them. This is in keeping with the Cyber Essentials user access control requirement.
- Do not trust shared caches blindly. Separate caches between privileged and unprivileged workflows and avoid restoring caches into jobs that hold publishing credentials.
- Add a cooldown to auto-updating developer tools. Depi suggests a short delay before adopting new releases of agentic tools such as Codex CLI. Pin versions in build images and approve upgrades deliberately, in line with Cyber Essentials secure configuration and security update management.
- Harden your own disclosure process. If you run a bounty or VDP, make sure triage staff are briefed to assess supply-chain and CI/CD reports on full chain impact, not the severity of the first link.
Bottom line
Depi’s research shows how an AI agent added to an automation pipeline for convenience can become the first step towards a supply-chain compromise. OpenAI fixed the flaw fast, and no harm is known to have been done. The open question is the reward: until the final assessment lands, a $1,000 opening offer for a plausible path to backdooring a widely used developer tool will be read by researchers as a statement of value, and UK teams should read the technical lessons as a prompt to check their own pipelines.
Sources
- Depi Security: Backdooring the next release of Codex through GitHub Action pipeline exploit chaining
- SecurityWeek: In Other News: New CISA Director Nominee, Connected Car Hacking, Baker Tilly Data Breach
- The Defiant: Researchers Say Codex Flaw Put npm Releases at Risk
- Help Net Security: OpenAI raises top bug bounty payout to $172,000 with bonuses