A bug report should help developers fix software. According to cybersecurity company Depi, a malicious one could instead have opened a path to compromising the systems used to distribute OpenAI’s Codex.
In its newly published research, Depi describes an attack chain that started with prompt injection in a GitHub issue and reached toward software publishing authority. The company says OpenAI has fixed the core flaw and that users have nothing to patch for this issue.
Depi’s representative subsequently clarified that the researchers demonstrated the full attack chain in a test repository without interacting with OpenAI’s infrastructure. The findings describe a potential route to compromising Codex distribution, rather than a demonstrated takeover of OpenAI’s production systems.
Codex CLI is OpenAI’s coding agent that runs locally on a computer. Its installation instructions include the official @openai/codex npm package, making the infrastructure behind that package an attractive target.
The concern is straightforward. If attackers can interfere with a trusted software release, users could install something harmful through the same channel they normally rely on for legitimate updates.
According to Depi, the starting point was an automated system that read GitHub issues and assigned labels. That sounds like a modest job, but the researchers describe a route from instructions planted in an issue to command execution, access to runner credentials, cache poisoning, and eventually a path toward npm publishing authority.
Prompt injection is what happens when an AI system treats hostile content it is supposed to examine as instructions it should follow. In this case, the alleged danger extended beyond the agent choosing the wrong label or producing a strange response.
In the test repository, the surrounding automation gave that mistake somewhere to go. The demonstrated chain included a later step that depended on a maintainer deleting a planted release.
That dependency matters when evaluating the findings. A chain requiring another person to take a particular action should not be described as an unconditional, one-step takeover.
The test demonstrated the attack technique, but it does not establish that a malicious Codex package reached users. Depi’s representative said using the test repository allowed the researchers to stay within OpenAI’s responsible disclosure policies and safe harbor.
According to a timeline provided by Depi’s representative, the researchers reported the issue through Bugcrowd on May 13, 2026. Bugcrowd triaged it that night, an OpenAI employee acknowledged that a fix was underway on May 14, and OpenAI deployed the fix on May 15.
The supplied fix time, 19:41:19 UTC on May 15, matches the merge time of OpenAI’s public workflow update. That change restored the issue-labeling workflow with a read-only sandbox and a setting that removes elevated privileges before the agent runs, although the public change itself does not name Depi.
The current workflow also separates suggesting labels from applying them. The agent’s label-suggestion job has read access to repository contents, while a separate job receives permission to edit issues.
That is the kind of separation this task deserves. An assistant deciding whether a complaint concerns Windows, authentication, or performance should have very little authority over anything else.
GitHub has changed its own infrastructure, too. On June 26, it introduced read-only cache access for certain untrusted workflow triggers that use the default branch’s execution context and cache scope.
Previously, those workflows could receive cache tokens with write access. GitHub explained that an attacker could poison a cache and wait for a more trusted workflow to restore it, potentially gaining code execution and access to production secrets.
Those dates matter because November publication does not mean the described setup remained exposed until November. The research needs to be read alongside the changes made to both the repository and the platform hosting its automation.
There is a catch for other teams reviewing their defenses. GitHub’s September introduction of cache-mode controls lets administrators explicitly grant write access even where the platform would otherwise use a read-only default. GitHub warns that doing so for low-trust events can increase the risk of cache poisoning.
For me, the uncomfortable part is how ordinary the starting point was. Public bug reports are supposed to be something a project can safely receive, including from strangers.
AI makes it tempting to hand that incoming work to an agent and move on. But the security review cannot stop at whether the agent usually follows its prompt. It also needs to cover the credentials it can reach, the files and caches it can change, and the more powerful jobs that might later consume those changes.
Look, folks, an automated labeler does not need a route into software distribution. If a malicious bug report can create one, the permissions around the agent need as much scrutiny as the model itself.
Update, November 11, 2026: Depi’s representative clarified that the full attack chain was demonstrated in a test repository without interacting with OpenAI’s infrastructure. This article has been updated with that clarification and Depi’s disclosure and remediation timeline.
Support independent tech journalism
NERDS.xyz is independently owned and operated. If you enjoy my coverage of Linux, AI, hardware, cybersecurity, and tech culture, consider supporting the site on Ko-fi.
Support NERDS.xyz
