Cordyceps Found 300+ Exploitable GitHub Repos at Microsoft, Google, and Cloudflare. The Bug Is in Your CI YAML — and Your AI Agent Is Writing More of It.

On June 24, Novee Security disclosed a class of GitHub Actions flaws it's calling Cordyceps. The short version: CI/CD workflows that hand pull requests more permission than they should, in a way that lets an outsider run code on your build pipeline. The firm scanned around 30,000 high-impact repositories and found more than 300 fully exploitable, including repos at Microsoft, Google, Apache, and Cloudflare. On one Microsoft repo, a researcher showed a pull-request comment could run attacker code on Microsoft's CI and lift a non-expiring app key. A pull request on a Google repo could execute attacker code and take over a Google Cloud repository.

The reason this matters to you, a solo operator with a handful of repos, is that the bug isn't in a package you imported. It's in the YAML file in your own .github/workflows directory, and if an AI agent scaffolded that file, there's a real chance you've never actually read it.

The actual problem: workflows are code, not config

Here's the trap Cordyceps exploits. A GitHub Actions workflow file looks like configuration. It's YAML, it sits in a folder, it describes "when X, do Y." So people treat it the way they treat a config file: write it once, copy it from a template or a chatbot, never audit it again.

But that file isn't config. It runs shell commands. It holds secrets and tokens. It can publish releases, push to your registry, and deploy to production. It's some of the most privileged code in your repo, and it's the code people read the least.

The specific danger is in how workflows handle pull requests from forks. There's a trigger called pull_request_target that runs the workflow with your repository's permissions and secrets, in the context of an incoming pull request. It exists for legitimate reasons (labeling PRs, leaving comments) but the moment such a workflow checks out and runs code from the fork, you've handed a stranger's code your repository's credentials. As Novee put it, the flaw is exploitable by any unauthenticated user: a free GitHub account is enough to open a pull request and, in a vulnerable repo, forge approvals, push code, or steal credentials.

That's the whole class. It's not one CVE you patch. It's a structural mistake that gets copied around.

Why this is getting worse, not better

The depressing accelerant is AI coding agents. When you ask an agent to "set up CI for this repo," it generates a workflow file from the same patterns that are already out there, including the insecure ones. The model doesn't know that pull_request_target plus a fork checkout is a credential handoff; it knows that's what a lot of workflow files look like. So the bad pattern reproduces at machine speed, in repos whose owners never learned why it's bad.

I've done exactly this. Asked for a CI workflow, gotten one that worked, merged it, moved on. It built and deployed, so it was "done." Whether it quietly trusted forked code was not a question I asked, because the thing ran. That's the gap Cordyceps lives in: the workflow works perfectly for its happy path and is wide open on the path nobody tests.

GitHub itself has been hardening the surface (it updated its widely used actions/checkout around mid-June to block a category of these "pwn request" attacks) but a platform fix doesn't reach into your repo and rewrite your YAML. The misconfiguration is yours to find.

The 15-minute Saturday audit

You don't need a security team. You need to read your own workflow files with the right question in mind. For each repo that matters:

1. Grep for the dangerous trigger. Search your workflows for pull_request_target and workflow_run. If you have neither, your fork-PR exposure is low and you can relax on this specific issue. If you have them, keep going.

grep -rn "pull_request_target\|workflow_run" .github/workflows/

2. Check what runs after that trigger. The danger is a pull_request_target workflow that then checks out the PR's head (the fork's code) and runs it (a build, a test, an install script). If the workflow only reads metadata and posts a comment, it's probably fine. If it does actions/checkout with ref: ${{ github.event.pull_request.head.sha }} and then executes that code, that's the live wound. Split trusted and untrusted steps into separate workflows so untrusted code never runs with your secrets.

3. Scope your token down. At the top of each workflow, set permissions explicitly to the minimum:

permissions:
  contents: read

The default GITHUB_TOKEN is far more powerful than most jobs need. Restricting it limits what a hijacked workflow can actually do, even if something slips through.

4. Pin third-party actions by commit SHA, not by tag. uses: some/action@v3 follows a moving tag that the action's owner can repoint at new code. uses: some/action@<full-40-char-sha> pins exact code you've seen. This closes the door on a compromised action shipping you a new payload under an old version number.

5. Don't let secrets near forked PRs. A pull request from a fork should never need your production secrets to be validated. If your CI passes deploy keys or provider tokens into jobs that run contributor code, move that work to a trusted, post-merge workflow.

The honest take

None of this is new security knowledge. Secure-CI advice has existed for years, and the people who needed to hear it mostly didn't. What's new is the scale of the exposure and why it's growing: agents minting workflow files faster than anyone reviews them, in a file type everyone misfiles as harmless config.

So the durable habit isn't "memorize the pull_request_target rule." It's: treat anything an agent writes into .github/workflows as production code that deploys with your keys, and read it like you'd read a function that does. The reason 300-plus repos at the largest companies on earth were exploitable isn't that their engineers are careless. It's that workflow YAML is the code we all skim. Spend the fifteen minutes this weekend reading yours.

Author

Lukas

@lukcombinator

Sources

• Cordyceps CI/CD Flaws Expose 300+ GitHub Repositories to Supply-Chain Attacks — The Hacker News
• Cordyceps: The Silent Parasite Consuming Your Supply Chain — Novee Security
• 'Cordyceps': Malicious Pull Requests Threaten CI/CD Workflows — Dark Reading
• Exploitable CI/CD Vulnerabilities Expose Millions of Repositories to Hijacking — SecurityWeek