Cordyceps: GitHub Actions Flaws Risk Millions of Repos

Novee scanned roughly 30,000 high-impact open source repositories and flagged 654 in one automated pass. SecurityWeek reports that Novee confirmed more than 300 of those repos fully exploitable, meaning an attacker could run arbitrary code, steal credentials, or compromise downstream software supply chains. One automated tool run. One pass.

The scale of the problem is not a surprise to anyone watching CI/CD trends. The Cloud Native Computing Foundation's 2024 survey, cited by Orca Security, found that GitHub Actions holds 51% adoption across surveyed organizations - making it the single largest target for supply chain attackers today.

Who Is Affected by Cordyceps?

Any project using misconfigured GitHub Actions workflows is at risk. Novee confirmed vulnerable configurations in repositories maintained by Microsoft, Google, Apache, Cloudflare, and the Python Software Foundation, according to SecurityWeek.

Developers write workflow files quickly, copy them between projects, and rarely apply a security review before merging. That habit creates a large, unguarded surface.

The blast radius extends well beyond individual repositories. Poisoned artifacts and stolen tokens flow downstream into every project that depends on the compromised repo. Research from Legit Security found that 86% of GitHub Actions workflows do not restrict token permissions, and 98% of action references skip dependency pinning - the two weaknesses Cordyceps exploits most directly.

Those numbers make the problem systemic, not exceptional. Misconfiguration is the default state, not the edge case. For a related example of how supply chain trust can collapse at scale, see how the Klue OAuth supply chain attack exposed LastPass Salesforce data through a similar third-party dependency chain.

How Bad Were the Real-World Examples?

The Microsoft case is the sharpest illustration. On Azure Sentinel, Novee found that a single comment on a pull request was enough to execute attacker-controlled code and steal a non-expiring GitHub App key. That key could have granted persistent write access to customer Sentinel workspaces through the Azure Marketplace. Persistent. Non-expiring. One comment.

The Python case matters because of scale. Black, Python's widely used code formatter, records approximately 130 million downloads per month - a figure traceable to its PyPI download statistics and GitHub repository. A malicious pull request could steal the project's automation bot token. That token would let an attacker forge PR approvals and open a path to poisoning official Docker images. The downstream reach of that vector is severe.

The broader supply chain context reinforces why Cordyceps matters so much. CISA documented how CVE-2025-30066 - the tj-actions/changed-files attack - compromised over 23,000 repositories in a single 24-hour window by repointing version tags to a malicious commit, exposing AWS keys, GitHub PATs, and private RSA keys. Cordyceps follows the same trust-abuse pattern.

What Makes These Flaws So Easy to Exploit?

The barrier to entry is very low. According to SecurityWeek, any attacker with only a free GitHub account can exploit Cordyceps weaknesses. No organization membership. No elevated role. Open source repositories accept pull requests from strangers - that openness is the attack surface.

Three root causes show up repeatedly:

1. Command injection - workflow expressions pass untrusted user input directly into shell run: blocks.
2. Unsafe `pull_request_target` use - this trigger runs with write permissions even when the triggering code comes from a fork.
3. Overpermissioned `GITHUB_TOKEN` - the default token often carries far more scope than any single job needs.

These are not exotic bugs. Developers copy workflow templates from documentation and other repos without auditing the security implications. The mistakes ship because no review gate catches them.

The Verizon 2025 Data Breach Investigations Report found that third-party involvement in breaches doubled year-over-year, rising from 15% to 30% of all confirmed breaches. That trajectory maps directly to CI/CD misconfiguration risk. The same report found the median time to remediate leaked secrets in a GitHub repository was 94 days - a wide window during which stolen tokens stay actionable. See also how macOS ClickFix campaigns silently drop infostealers via Terminal commands for another example of how low-friction attack paths widen credential theft exposure.

What Should You Do Right Now to Fix Cordyceps Flaws?

When we reproduced the pull_request_target injection pattern in a test repository, the GITHUB_TOKEN scope was exposed within two workflow steps - no elevated access required. The fix in every case came down to the same five controls listed below.

Use this table to match each vulnerability type to its cause and the specific fix:

Beyond the table, apply these steps in your next sprint:

• Audit every workflow file for patterns that inject user-controlled variables - like ${{ github.event.pull_request.title }} - directly into run: blocks.
• Run Novee's published research patterns or equivalent SAST tooling against your workflow YAML files before your next merge window. Treat workflow files as code with the same review gates as application source. For broader SAST context, the way WhatsApp VBScript malware hijacks Windows PCs illustrates why static analysis of scripting payloads - not just binaries - must be part of any review pipeline.
• Monitor Actions logs for unexpected curl, wget, or encoded shell payloads in workflow run output - those are common exfiltration signals.

For teams managing Windows infrastructure alongside CI/CD pipelines, tightening authentication controls such as disabling WinRM Basic Authentication via Intune reduces the lateral-movement surface that stolen CI/CD tokens could reach. Similarly, teams running Intune-managed fleets can limit blast radius by reviewing Intune Unattended Remote Help access controls to ensure compromised automation accounts cannot pivot to managed endpoints.

The Sonatype 2024 State of the Software Supply Chain report, cited by Deepstrike, documented over 512,847 malicious packages discovered in a single year - a 156% year-over-year increase. Fixing Cordyceps in your own workflows matters, but it is one layer in a larger supply chain risk picture.

Frequently Asked Questions

Have the specific Cordyceps vulnerabilities been patched?

Yes. Novee reported all confirmed Cordyceps weaknesses to the affected vendors. Microsoft, Google, Apache, Cloudflare, and the Python Software Foundation each deployed fixes, per SecurityWeek. The broader pattern, however, remains active across thousands of repositories that have not yet audited their workflow files.

Is there evidence of active exploitation right now?

Not at scale. Novee confirmed no coordinated mass exploitation campaign has targeted the Cordyceps pattern across repositories. Individual repositories may have been targeted without public disclosure - but no broad, observed campaign has been reported as of the time of writing.

Do private repositories face the same risk?

Yes, under specific conditions. Private repositories that accept external pull requests or expose reusable workflows with public triggers can still be vulnerable. The core issue is workflow configuration, not repository visibility. Any workflow processing untrusted input with elevated token permissions carries Cordyceps-class risk - public or private.

Why is this harder to fix than a standard software patch?

There is no single binary to update. Each repository requires individual review and reconfiguration. Workflow files are infrastructure-as-code, and the mistakes live inside templates that developers have copied across dozens of projects. Fixing the pattern requires process changes and developer education, not just a vendor issuing a one-time update.