"A scanner sees a workflow. An attacker sees a four-step chain to a permanent credential," explains Shane Warden, Principal Architect at ActiveState. That sentence—lifted from Warden's June 2026 analysis—is the clearest way to understand Cordyceps, the class of CI/CD weaknesses disclosed by researchers at Novee Security.
What Cordyceps is and how it works
Novee Security reported that it scanned roughly 30,000 high-impact repositories across npm, PyPI, crates.io, and Go, flagged 654 repositories for attention and confirmed more than 300 as fully exploitable. The pattern exploits how GitHub Actions composes multiple, individually valid workflow files into a privileged end state. The key actors are two GitHub trigger contexts—pull_request_target and workflow_run—which run in the base-repository context with access to secrets and a read/write GITHUB_TOKEN, while pull_request runs in the untrusted fork context without secrets and with a read-only token.
An attacker with nothing more than a free GitHub account—no org membership, no elevated privileges—can craft a pull request that induces those privileged triggers to act on attacker-controlled input. GitHub Security Lab calls that sequence a "pwn request." The attack uses three primitives: command injection (attacker-controlled branch names, titles or comments interpolated unescaped into shell commands), code injection via actions/github-script (evaluating attacker input as JavaScript at runtime), and cross-workflow privilege escalation (a low-privilege workflow writes untrusted data that a second, high-privilege workflow later reads and acts on). None of the individual workflow files are syntactically incorrect; the danger is in their composition.
Proofs against Microsoft, Google and Apache
Novee demonstrated concrete chains against major projects. On Microsoft's Azure Sentinel repository, researchers showed that a comment on a pull request could execute anonymous attacker code on Microsoft's CI and steal a non-expiring GitHub App key—an outcome confirmed by Microsoft's Security Response Center. Sentinel is the SIEM whose Content Hub ships detection rules and automated playbooks into customer workspaces; a stolen key could give persistent write access to the security content thousands of organizations rely on.
Google's AI Agent Development Kit sample repository likewise contained a composition that allowed a single pull request to run code in Google's CI and escalate to roles/owner on the associated Google Cloud project, producing permanent owner-level access, a finding confirmed by Google. Apache Doris had a comparable path to credential theft; the Apache Security Team confirmed and fixed that path. Novee found no evidence of exploitation in the wild, and the named vendors hardened or patched the demonstrated chains, but the pattern remains broadly unpatched by default.
Why standard scanners reported green
The reason every affected pipeline reported healthy checks is simple: the security scanners were not designed to evaluate cross-file composition. Traditional SAST and DAST tools pattern-match single workflow files; each YAML file in Cordyceps is valid and well-formed. As Warden put it, "There is no single line to flag, because no single line is wrong." The measurement trap is this: a green light from a scanner sends people home, even though the composition of those green files produces an exploitable chain.
Compounding the risk, Novee warns that agentic, AI-driven tooling reproduces the same insecure CI/CD patterns at scale. AI-generated workflows can multiply a single mistake across potentially millions of repositories and do so without a provenance signal; human review points in a pipeline are being overwhelmed by the volume of decisions AI now produces.
Immediate mitigations and a durable control
- Prefer pull_request over pull_request_target for untrusted contributions.
- Never check out pull request head code inside a privileged workflow.
- Pass event data through a quoted environment variable rather than inlining it, and avoid interpolating unescaped PR data into shell commands.
- Default permissions to read-only and pin third-party actions to a commit SHA rather than a moving tag.
- Gate privileged workflows behind manual approval for first-time contributors.
Those steps close many immediate paths, but Novee and Warden argue for a durable control: govern what your build system trusts at the source. Components and workflows entering the pipeline should come from a governed origin with verifiable provenance and be built from source rather than trusted on faith. Human ownership of trust boundaries must operate at the speed of AI-generated changes, because manual review at the far end of the pipeline cannot catch up.
What this means for maintainers, enterprise security teams, and NIST
Maintainers should treat workflow triggers and cross-workflow outputs as trust boundaries to be explicitly reviewed and hardened—prefer safer triggers, pin actions, and require manual approvals for unfamiliar contributors. Enterprise security teams must treat CI/CD as an attack surface that can provide persistent downstream impact (for example, Sentinel's Content Hub or a Google Cloud project's owner role) and adopt gating and provenance checks at ingestion points. NIST acknowledged in April 2026 that it can no longer enrich every CVE—submissions are up 263% since 2020—underscoring that Cordyceps, which is not a CVE, will likely evade enumeration models unless governance and discovery processes change.
Cordyceps did not defeat security tools; it walked past them because every piece did exactly what it was supposed to do. The hard truth remains: a green pipeline is not a governed one. Fix the trust boundary at the source, and then verify what crosses it.
