300 GitHub Repos Could Be Hijacked by Anyone With a Free Account. The Bug Has No CVE.

A penetration-testing startup called Novee Security spent a scan looking at roughly 30,000 popular open-source repositories on GitHub. It came back with 654 that looked exploitable and more than 300 it says it confirmed all the way through: an anonymous person with a free account could run their own code inside the project's automation, steal credentials, and in several cases take over the cloud account behind it. The list of affected projects includes Microsoft's Azure Sentinel, a Google AI sample repository, Apache's Doris database, Cloudflare's Workers SDK, and the Python code formatter Black.

Novee published the research on June 23 and gave the pattern a name: Cordyceps, after the fungus that hijacks insects and drives them around like puppets. The name is doing some marketing work, but the underlying finding is real and worth understanding, because the flaw is not in any one piece of software. It is in how thousands of teams wire their automation together.

What actually breaks

Start with the plumbing. CI/CD stands for continuous integration and continuous deployment, which is the automated pipeline that runs every time someone proposes a code change. On GitHub, those pipelines are built with a feature called GitHub Actions: short scripts, written in YAML files inside the repository, that run tests, build releases, sign artifacts, and log into cloud providers. They are treated as configuration. They are actually code, and they run with real permissions.

A pull request is a proposal to merge code into a project. Anyone can open one. Anyone can leave a comment on one. The bug Novee describes is that a lot of these workflows take that untrusted input, a branch name, a pull request title, a comment body, and act on it as if a trusted maintainer had typed it. Feed a workflow a branch name with shell commands hidden in it, and the workflow runs your commands. With the project's permissions.

The dangerous findings were not single mistakes. They were chains. An untrusted pull request triggers a low-privilege workflow. That workflow's output gets passed into a second, higher-privilege workflow. The second workflow holds a token that can log into the project's cloud account. No individual step looks wrong. Each file is valid. The hole only exists in the handoff between them, which is exactly the kind of thing a scanner reading one file at a time does not catch. Novee's own framing for this is honest: "The workflow does what it was told. The vulnerability exists only in the composition."

The barrier to entry is the part that should get attention. Per Novee's writeup, you do not need to be a member of the organization or have any special access. A free GitHub account is enough.

The named findings

These are the cases Novee says vendors confirmed, with the affected company's security team credited in each.

A few of these matter more than the demo value suggests. Azure Sentinel is Microsoft's security product, and the repository feeds detection rules into customers' environments through the Content Hub. Black is installed something like 130 million times a month, by Novee's count, so a token that can approve merges there reaches a lot of downstream machines. The Google case turns one pull request into owner-level control of a cloud project.

What this is not

It is not a single vulnerability, and it does not have a CVE. Novee is explicit that "the silent parasite consuming your supply chain doesn't get a CVE," because each instance is a configuration choice rather than a defect in a shared component. That cuts both ways. There is no one patch that fixes all of it, but there is also nothing forcing every project to be vulnerable. The fix, project by project, is to stop letting untrusted triggers run with privileged tokens and to keep untrusted output from flowing into privileged workflows.

It is also not a GitHub flaw. Novee says the same pattern exists on any workflow system; GitHub is just the biggest target. And, worth saying plainly: there is no claim in the research that any of this was exploited in the wild. Novee found these by scanning and reporting them, not by catching an attacker mid-theft. This is a disclosure, not a breach.

The part that is genuinely new

The reason to care now rather than at any point in the last five years, when these workflow features already existed, is the rate. Novee's argument is that AI coding agents generate CI/CD configuration quickly and reproduce the same insecure patterns over and over, so the mistake spreads faster than humans would make it. That tracks with how these tools work. They pattern-match against existing code, and a lot of existing GitHub Actions code is permissive by default. If the bad pattern is in the training data, the agent will keep emitting it.

That claim is Novee's, and it fits the company's product, so weigh it accordingly. Novee sells AI-driven penetration testing and a service it calls Continuous External Attack Validation, and the writeup ends with a sales pitch. The "millions of repositories potentially affected" line is an extrapolation, not a count. The number Novee actually stands behind is the 300-plus it says it confirmed.

Strip the framing and the engineering still holds up. Workflow files are code. They run with credentials. Most security tooling never reads them, and the most dangerous bugs live in the seams between two files that each look fine on their own. If you maintain anything on GitHub, the cheap move this week is to look at which of your workflows can be triggered by a stranger's pull request, and what those workflows are allowed to touch. That is where the body-snatching starts.