Prompt injection attacks are no longer only a chatbot problem. GitHub Actions security now includes a simpler question: if a workflow hands an AI agent the text of a GitHub issue, a comment or a pull-request description, who actually wrote that text?
On 11 November 2026, security firm Depi disclosed a path that started with a crafted GitHub issue in OpenAI's Codex repository and could have reached the credentials needed to publish the official @openai/codex package on npm. That is the shape of an npm supply chain attack, even though coverage of Depi's write-up does not describe any malicious release reaching users. SecurityWeek, in a 13 November roundup, says OpenAI has fixed the issue and awarded an initial $1,000 bounty.
You do not need to use Codex for this to matter. The same pattern now shows up in agency and product repositories: an agent that labels issues, summarises pull requests or runs a step in CI, reading text that anyone can type into the repo.
What the researchers reported
Depi's write-up, by Pierre Martin (Worty) and Garance de la Brosse (Madder), says the entry point was an issue-labeling workflow in the openai/codex repository. The workflow used a Codex action to read newly opened issues and suggest labels. It was set up so that anyone who could open an issue could have that issue's title and body processed by the agent. Both fields were passed straight into the agent's prompt. SecurityWeek describes the same starting point as a prompt injection in a GitHub Actions workflow.
From there, Depi describes a chain that could have given an attacker a path to publish a malicious version of @openai/codex. Writeble, reporting on the same disclosure on 12 November, says the chain was demonstrated against a test environment, and that the write-up does not describe any malicious release reaching users. Depi says it reported the chain to OpenAI through Bugcrowd with a full proof of concept, and that OpenAI "deployed a fix right away." Depi and SecurityWeek both report an initial bounty of $1,000; Depi says the report is still under further review.
Depi also says @openai/codex is downloaded millions of times a month. That figure is Depi's, not an independent count, and this article does not add a download number of its own.
We are not walking through the exploit chain here. The useful fact for anyone who maintains a repository is the starting point: a workflow trusted text that strangers could write.
Why prompt injection attacks matter to site owners
Many site builders, agencies and product teams now let AI agents triage issues or run steps in GitHub Actions. That is convenient. It is also an AI agent security problem if the agent is treated as a trusted reviewer of untrusted input.
If an agent reads issues, comments or pull-request descriptions, the people who wrote those texts can try to give it instructions. Our guide to AI agent security is about that broader risk: an agent is only as trustworthy as the tools, credentials and inputs you give it.
The Codex case is also a reminder that software supply chain security can fail one step before a release job. A workflow that only "labels issues" still runs in an environment that may share tokens, caches or later jobs with the pipeline that publishes a package. Token hygiene after an incident, and the habit of rotating anything a workflow could have exposed, is the same discipline we described after the Apify API token rotation. For the APIs your site or app already exposes, the same idea applies: API security vulnerabilities often start with a trusted path that accepted more input than it should have.
What to check this week
- List the workflows that read outside text. Search for jobs that run when an issue is opened, a comment is posted, or a pull request arrives, and that pass that text to an agent, a script or a prompt. If anyone can open an issue in the repo, treat that text as untrusted.
- Give those jobs the least privilege they need. Run issue-triage and labeler workflows with read-only tokens. Do not attach package-publish, release or write permissions to a job whose only task is to read someone else's text.
- Keep release workflows away from shared caches. Privileged jobs that build or publish should not trust a cache that a less-trusted workflow can write. If a labeler job and a release job can share a cache, they are closer than they look.
- Pin and review the actions you call. Know which action versions run in those workflows, and who can change them.
- Decide what an agent is allowed to do. If it can run commands, open a network path or write to the repository, untrusted text is not "just data."
None of these steps is a substitute for OpenAI's fix in Codex itself. They are the checks that still apply in your own repositories.
While you are reviewing what your own site exposes from the outside, a look at security for a website can show outside-in findings on a domain you own or have permission to test. It is not a GitHub Actions auditor, and it will not scan your workflows. We build HackerMe.
FAQ
Was a malicious Codex package published to npm?
No source reviewed for this article describes a malicious @openai/codex release reaching users. Depi says OpenAI fixed the core bug. Writeble notes that the chain was demonstrated against a test environment.
Do I need to patch Codex on my machine?
Depi says OpenAI fixed the core bug that enabled the chain, so there is nothing for end users to patch on their machines. The takeaway is about how your own workflows treat untrusted text, not a client-side patch.
What should I change in GitHub Actions if we use an AI agent?
Do not pass issue titles, issue bodies, comments or pull-request descriptions to an agent in a job that has write, release or publish permissions. Use read-only tokens for those jobs, and keep privileged release workflows from trusting shared caches.
Originally published on the HackerMe security blog.
Top comments (0)