Cordyceps Supply Chain Flaw Puts CI/CD Workflows at Risk Across Major Code Repositories

A newly disclosed supply chain weakness called Cordyceps is putting code repositories and CI/CD pipelines at risk by turning normal automation workflows into paths for repository takeover, credential theft, and malicious code changes.

Security firm Novee says its researchers scanned roughly 30,000 high-impact repositories and found hundreds of exploitable attack chains. The affected patterns appeared in projects connected to major organizations, including Microsoft, Google, Apache, Cloudflare, and the Python Software Foundation.

The issue matters because CI/CD workflows often do far more than run tests. They can execute shell commands, hold secrets, authenticate to cloud accounts, publish releases, and update protected branches. A small workflow mistake can therefore become a software supply chain problem.

What is Cordyceps?

Cordyceps is the name Novee gave to a class of CI/CD security flaws that hide inside workflow logic. The name refers to the parasitic fungus, because the weakness can let an outsider use a trusted project’s own automation against it.

In practical terms, the flaw appears when untrusted input from pull requests, branch names, issue comments, or workflow artifacts crosses into a more privileged workflow. No single step may look obviously dangerous, but the chain can still give an attacker control over build systems or credentials.

This is especially serious in GitHub Actions, which developers use to automate build, test, and deployment tasks directly inside repositories. GitHub Actions itself is not the flaw, but its wide use makes insecure workflows attractive targets.

Area	What Cordyceps abuses	Possible impact
Pull requests	Untrusted titles, branch names, or code from outsiders	Command execution in CI jobs
Issue comments	Comment text passed into scripts or workflow logic	Credential theft or unauthorized workflow actions
Workflow artifacts	Files passed from low-privilege jobs into high-privilege jobs	Cross-workflow privilege escalation
Cloud authentication	CI jobs with broad cloud roles or long-lived secrets	AWS, GCP, Netlify, or package registry compromise

How attackers can exploit the weakness

The Cordyceps pattern can start with something as simple as a pull request or a comment. An outsider may not need membership in the organization. A free GitHub account can be enough if the workflow accepts attacker-controlled input and later runs it with higher privileges.

For example, a low-privilege workflow may process a pull request and create an output artifact. A second workflow may trust that artifact and run with write access, deployment permissions, or cloud credentials. The dangerous part sits between the two workflows.

The OWASP GitHub Actions Security Cheat Sheet warns that GitHub workflow misuse can lead to attacker-controlled code execution. That risk becomes larger when workflows use untrusted context values inside shell commands or scripts.

Major projects were reportedly affected

Novee says it confirmed more than 300 fully exploitable repositories after flagging 654 repositories in one scan. The reported impact included code execution, credential theft, protected-branch manipulation, forged checks, bot impersonation, and possible package publishing abuse.

In one Microsoft Azure Sentinel example, Novee reported that a pull request comment could lead to theft of a non-expiring GitHub App key. In Google’s AI Agent Development Kit samples, the company said a pull request could lead to authenticated control over an associated Google Cloud project.

Novee also described two attack paths in Apache Doris and a crafted-branch-name issue in Cloudflare’s Workers SDK. According to the Cordyceps report, fixes were confirmed at several large organizations after disclosure.

• Microsoft Azure Sentinel: reported GitHub App key theft path.
• Google ADK samples: reported cloud-role escalation path.
• Apache Doris: reported credential theft and write-permission paths.
• Cloudflare Workers SDK: reported command execution on CI runners.
• Python Black: reported bot-token abuse path tied to automation workflows.

Why traditional scanners may miss it

Cordyceps is hard to catch because it often depends on the relationship between multiple workflows. A scanner looking at a single YAML file may see valid configuration, while an attacker sees a path from untrusted input to privileged execution.

GitHub’s own secure use guidance recommends limiting what workflows can do, keeping actions updated, and using code scanning to detect risky workflow patterns. These controls help, but they still require teams to treat workflow files as security-critical code.

The OpenSSF guidance also recommends separating workflows that handle untrusted code from workflows that use secrets or write permissions. That separation is one of the most important defenses against cross-workflow escalation.

Weak pattern	Why it is risky	Safer approach
Running untrusted PR content with write permissions	Attackers may run code with maintainer-level authority	Use read-only permissions for untrusted pull request workflows
Passing artifacts into privileged workflows without validation	Attackers can poison trusted inputs	Validate artifacts and keep trust boundaries clear
Using broad cloud roles in CI jobs	A stolen token may give wide infrastructure access	Use least privilege and short-lived credentials
Interpolating user-controlled values into shell commands	Branch names or comments may become command injection	Sanitize inputs and avoid direct shell interpolation

AI coding agents may increase the scale of the problem

Novee argues that AI coding agents are making the issue spread faster because they can generate CI/CD configuration at scale. When those tools repeat insecure patterns, the same weakness can appear across many repositories.

The risk does not come from AI alone. It comes from placing automation, cloud access, secrets, and untrusted repository content in the same execution path. AI-generated workflows can accelerate that problem if developers do not review them like application code.

Teams using GitHub Actions workflows should therefore review generated CI/CD files before merging them. Workflow YAML should go through security review, just like code that handles authentication, payments, or production deployment.

What organizations should do now

Security teams should audit workflows that run on pull_request, pull_request_target, issue_comment, workflow_run, and workflow_dispatch events. These triggers often sit near trust-boundary mistakes because they can respond to outside users or pass data between jobs.

Teams should also review whether any workflow writes to protected branches, publishes packages, signs releases, deploys cloud resources, or uses long-lived secrets. These jobs deserve stricter permissions, manual approvals, and tighter input validation.

The GitHub secure use reference and the OWASP cheat sheet both support the same core principle: workflows should use the least access needed, and untrusted input should never cross into privileged execution without validation.

• Treat CI/CD workflow files as security-sensitive source code.
• Set default workflow permissions to read-only where possible.
• Separate untrusted pull request jobs from jobs that use secrets.
• Avoid passing unvalidated artifacts between low-privilege and high-privilege workflows.
• Replace long-lived secrets with short-lived OIDC-based access where possible.
• Pin third-party actions and keep them updated.
• Review branch names, PR titles, comments, and issue bodies as attacker-controlled input.

The bigger software supply chain risk

Cordyceps shows that the modern software supply chain does not end with packages and dependencies. The build system itself has become part of the attack surface, and attackers know that CI/CD runners often hold the keys to releases and cloud systems.

The most exposed organizations are not only those that own vulnerable repositories. Companies that depend on affected open-source projects may also face downstream risk if a build pipeline gets poisoned before a trusted release ships.

That makes workflow security a board-level supply chain issue for large engineering teams. The practical fix starts with the same steps recommended by OpenSSF: separate trust zones, reduce permissions, review workflow composition, and stop treating CI/CD files as harmless configuration.

FAQ