Depi: how a GitHub issue could have backdoored the next Codex release

What happened#

On Nov 11, Depi's Pierre Martin and Garance de la Brosse published a write-up of a chain that starts with a GitHub issue and ends at the next release of OpenAI's Codex. They describe what could have happened. Neither the write-up nor the Bugcrowd listing says a backdoored release shipped.

The entry point was OpenAI's Issue Labeler workflow. It ran openai/codex-action with allow-users: "*" and put the title and body of any newly opened issue into the Codex prompt. That meant anyone with a GitHub account could write text the agent would read.

According to the Bugcrowd listing, the chain started with a prompt injection in that issue text. The researchers then got out of Codex's workspace-write sandbox through the runner's .NET debug pipes, read the runner process's memory and recovered GitHub tokens. From there the write-up carries those tokens toward the release pipeline.

Bugcrowd shows a disclosure date of Sep 29, priority P1, status Resolved and a $1,000 reward. Depi calls that an initial bounty and says the report is still under review.

Who is affected#

Codex users have nothing to patch. OpenAI fixed the core bug.

The teams that should read this closely run an agent in CI on text that strangers can write: issue titles, PR descriptions, comments. The Issue Labeler workflow had exactly that setup.

This is one write-up about one workflow, so it doesn't prove your setup is exploitable. It shows you where to look.

What to check this week#

• Search .github/workflows for agent actions (Codex, Claude Code, Copilot and similar) triggered by issues, issue_comment or pull_request_target.
• Look for open user allowlists like allow-users: "*". Limit them to the people who actually need to trigger the agent.
• List what the agent's job can reach: tokens in its environment, write permissions, caches shared with privileged workflows. Set permissions: to the minimum on every workflow.
• Keep agent jobs that read untrusted text away from release paths. Anything that can mint an OIDC token or publish a package shouldn't share a runner, cache or trust boundary with them.
• Test your sandbox mode instead of trusting its name. Depi got out of workspace-write through the runner's own debug pipes.
• Take the authors' advice: "a short cooldown on tooling that auto-updates is a good security practice." Pin coding agent versions and give a new release time to age before it reaches every laptop.
• Tell developers plainly that issue text is untrusted input, even when a bot reads it first.

Where Harden helps, and where it doesn't#

Harden Agentic Integrity Foundation (AIF) runs on the developer laptop, outside the agent, at the agent's pre-execution hook. It checks every command, file edit and push against the session's intent before it runs. Decisions are made locally, with verdicts in about 28 ms.

On a laptop, the same attack looks like an agent reading an issue, a README or a web page with hidden instructions in it. AIF judges the commands that follow, such as a secret flowing toward a network call, a base64 payload (decoded before analysis) or a push that doesn't fit what the developer asked for. The agent's own guardrails are no longer the last check.

It wouldn't have changed this chain. The chain ran on a GitHub Actions runner, so AIF wasn't in the path, and AIF doesn't protect hosted CI runners. It doesn't replace least privilege, scoped tokens or sandbox hardening, and it can't un-steal a token.

AIF also won't fix a poisoned agent release. A backdoored agent build can run code that never goes through its pre-execution hook. For that risk, rely on release cooldowns, version pinning and clean CI.

Read more#

For the laptop side of this problem, see how to protect coding agents from prompt injection.

• Backdooring Codex (Depi)
• Backdooring the next release of Codex through GitHub Action Pipeline exploit chaining (Bugcrowd)