Every open source repo with a CI workflow has already invited strangers into its runner. You just hope none of them notice. Researchers at Novee, an AI penetration testing platform, have handed that trust boundary a name: Cordyceps, a class of exploitable pattern in CI/CD workflows where anything a random GitHub user submits (a pull request, a comment) gets executed with maintainer authority.
The parasite reference is on the nose. Cordyceps hijacks hosts. This pattern hijacks pipelines.
What Novee actually found
The team scanned 30,000 high-impact repositories. 654 flagged in the initial pass. Over 300 confirmed as fully exploitable. Affected properties named in the writeup include Microsoft, Google, Python, Apache and Cloudflare. Ecosystems in scope: npm, PyPI and Go. The target surface: GitHub Actions workflows that treat outsider input as trusted context.
Two concrete outcomes are worth staring at.
At Microsoft, the chain lifted non-expiring GitHub App keys from Azure Sentinel SIEM, granting persistent write access to security content Microsoft ships to customers. At Google, an exploitable workflow gave unauthenticated control over the Google Cloud projects tied to the repo.
Read that again. A free GitHub account, no org membership, no special role, could push code into a security product's supply chain or take the wheel on a cloud project. Comforting.
The mechanic behind the parasite
You already know the ingredients. A workflow trigger that runs in the context of the base repository (with its secrets, its GITHUB_TOKEN write scope, its app installation credentials) then does something with the contents of an untrusted contributor's commit or comment. A checkout of the PR head. A script that reads a title, a body, a filename. An eval, an install, a template substitution. Every step, on its own, is boring. Chain them and you have code execution with the crown jewels attached.
Elad Meged, a founding engineer at Novee, made the point that SAST and DAST tools do not reason about cross-workflow findings. They audit files, not exploit chains. Each hop looks compliant. The story only appears when you walk the graph.
Is this a new class of bug? Not really. The pull_request_target footgun has been kicking around GitHub Actions security posts for years. Is it a new way to find the pattern at scale, across public infrastructure, with named victims? That is the interesting part.
Why your scanner missed it
Because it was not looking at the joins. Static analysis is good at "this file has a bad pattern". It is bad at "this file receives an artifact from that file which is written by a workflow triggered by that other event, and by the way the token is inherited from a reusable workflow two repos over". Reviewers reading a workflow one file at a time will nod at each step. So will regex policy engines. So will most PR review bots.
Cross-workflow reasoning is where the risk lives. It is also where nobody wants to spend an afternoon.
Triage for the week
Not a checklist, a triage. Do these in order:
- Grep every repo for
pull_request_targetandworkflow_run. Any workflow using those triggers that touches PR-controlled content is guilty until proven innocent. - Restrict
GITHUB_TOKENpermissions at the workflow level. Read-only by default, elevated per-job when the job actually needs to write. - Never check out PR-authored code inside a privileged workflow. If you must, run the untrusted step in a separate job with no secrets and no write token, and pass only inert artifacts across.
- Rotate any long-lived GitHub App key you cannot rotate on a schedule. Non-expiring credentials are why the Microsoft example was so ugly.
- Gate jobs that touch cloud identities or publish artifacts behind an environment with a required reviewer. Break the chain with a human.
None of this is new advice. It is just advice that keeps not being taken.
The perimeter is your triggers
For years, the working CI threat model has assumed the maintainer set is the perimeter. Cordyceps is the reminder that the perimeter is whatever your workflow triggers say it is, and your triggers say a lot more than you think.
Signed. Verified. Still exploitable, if the workflow lets a stranger drive.
Top comments (0)