Cordyceps: A Workflow Vulnerability That Breaks GitHub Actions Trust Boundaries
Cordyceps is a GitHub Actions workflow-chain vulnerability where untrusted pull request input from forks or public contributors can be passed into privileged CI/CD jobs, allowing attacker-controlled code, comments, artifacts, or metadata to reach secrets, powerful tokens, and deployment credentials even when standard security checks appear to pass. That is the uncomfortable takeaway: your CI may be "green" while silently exposing the keys to your infrastructure. Novee Security describes Cordyceps as a critical supply chain flaw in GitHub Actions that lets low-trust pull request activity cross into high-trust CI/CD workflows. This is not a bug in GitHub’s runtime; it is a design failure in how many teams structure their automation. Cordyceps is best understood as a trust-boundary failure, where contribution-side inputs like public pull requests, issue comments, or workflow artifacts are later consumed by jobs that have access to secrets, write permissions, deployment credentials, or a powerful GITHUB_TOKEN. In other words, the workflows themselves create the exploit path.
How Workflow Chains Turn Ordinary Events into CI/CD Token Exposure
The uncomfortable truth for GitHub Actions security is that many risks appear only when you look at workflows as chains, not as isolated files. A single workflow may look safe, but it becomes dangerous when another workflow later consumes its output, artifacts, labels, or checkout state. This is the essence of Cordyceps: untrusted input starts in a low-privilege context, then quietly crosses into a high-privilege job. GitHub Actions explicitly draws a sharp trust boundary between ordinary pull_request events and more powerful triggers. Workflows triggered by standard pull requests from forks are restricted: secrets are withheld and the default token is limited because public contribution workflows are exposed to untrusted users. In contrast, pull_request_target runs in the base repository’s context, which is valuable for policy checks but dangerous if it checks out or executes fork-controlled code. Even when a workflow does not name a secret, attacker-controlled code can still use a read-write repository token if the job grants one. That is CI/CD token exposure in practice, created by workflow design rather than platform failure.
Who Is Affected and Why Passing Checks Does Not Mean Safe
The scope of this workflow vulnerability is wide enough that no serious engineering organization can ignore it. In a review of roughly 30,000 high-impact open-source projects across npm, PyPI, crates.io, and Go ecosystems, Novee said 654 repositories entered its flagged set and more than 300 were confirmed as fully exploitable. Projects associated with Microsoft, Google, Apache, Cloudflare, and the Python Software Foundation appeared in the affected-tooling list. Cordyceps is an exposed exploit path rather than a confirmed mass-exploitation campaign, and Novee reported no evidence of exploitation in the wild. That absence of confirmed abuse should not lull maintainers into complacency. The problem is that workflows can pass all standard CI checks and code reviews while remaining vulnerable. The risk appears when privileged automation checks out, executes, evaluates, or blindly consumes attacker-controlled material. A workflow chain might pass static analysis, license checks, and typical CI gating while still allowing a pull request comment or artifact to drive a job with write access, secrets, deployment credentials, or broad cloud permissions. This is a blind spot in typical CI/CD security practices: they inspect code, but rarely inspect automation trust boundaries.
Why Default Protections Are Not Enough for Secrets Management
Many teams assume GitHub’s default restrictions for pull requests and the permissions key are enough to keep secrets safe. Cordyceps shows that this is wishful thinking. GitHub does document pull request restrictions because public contribution workflows are exposed to untrusted users, and it offers a permissions key to grant read, write, or no access to token scopes. But permissions hardening only reduces the blast radius; it does not make running attacker-controlled code in privileged jobs safe. This is a secrets management problem at its core. A workflow mistake can expose more than source code: it can expose repository tokens, package-publishing rights, cloud credentials, and release infrastructure. The failure occurs when low-trust input is later used by a privileged workflow that has access to repository authority such as secrets, write permissions, deployment credentials, or a powerful GITHUB_TOKEN. Long-lived keys, publishing tokens, and cloud owner roles are especially dangerous if wired into workflows that can be influenced by outside contributors. The lesson is clear: GitHub Actions security must include explicit secret-protection layers beyond default checks and permissions flags.
Immediate Mitigation: Audit Workflows, Restrict Tokens, and Gate Sensitive Jobs
Maintainers should treat Cordyceps as an urgent workflow vulnerability that demands a structured response, even in the absence of confirmed compromise. The most important rule is simple: untrusted pull request content must not run inside a job that has write access, secrets, deployment credentials, or broad cloud permissions. Teams should keep untrusted pull requests out of privileged jobs, minimize token permissions, validate artifacts passed between workflows, quote event data before shell use, and pin or update third-party actions deliberately. Concretely, organizations need to audit existing workflows and add secret-protection layers beyond default checks. They should review privileged triggers: audit every use of pull_request_target, workflow_run, issue comments, labels, and manually triggered workflows that consume pull request data. They must avoid checking out fork-controlled code inside privileged workflows unless the risk is explicitly handled, and set GITHUB_TOKEN permissions to the minimum needed using the permissions key. Protect secrets and cloud roles by keeping long-lived keys, publishing tokens, and cloud owner roles out of workflows exposed to external contributors. Finally, gate risky jobs with required reviews, protected environments, branch protections, and release approvals for workflows that publish packages, deploy infrastructure, or modify repository settings. In parallel, teams should turn on GitHub’s secret scanning and treat CI/CD token exposure as a first-class threat, not a secondary concern. The conclusion is blunt: CI/CD security is workflow security, and ignoring these chains is no longer acceptable.
- Audit all workflows for paths from untrusted input to privileged jobs.
- Use GitHub secret scanning and remove long-lived keys from exposed workflows.
- Minimize CI/CD token scope with the permissions key and prefer read-only tokens.
- Implement approval gates and protected environments for sensitive operations.
- Pin and regularly update third-party actions, and validate artifacts between workflows.
