The GitHub Actions Attack Pattern Your CI Security Scanners Miss
A green pipeline is not a governed one, and agentic coding is widening the gap faster than review can close it.
By Shane Warden, Principal Architect, ActiveState
In June 2026, researchers at Novee Security disclosed a
class of CI/CD weakness they named Cordyceps. They scanned roughly 30,000 high-impact repositories across the npm, PyPI, crates.io, and Go ecosystems, then flagged 654 and confirmed more than 300 as fully exploitable.
The affected build tooling included projects published by Microsoft,
Every one of those pipelines was green. The scanners ran, the checks passed, and the dashboards reported healthy results the entire time the exposure existed. The scanners were never built to see this danger.
The Vulnerability Is in the Composition, Not the File
GitHub Actions workflows are usually triggered by pull_request, which runs in the untrusted context of the fork, without repository secrets and with a read-only token. The trouble starts with pull_request_target and workflow_run, which run in the context of the base repository with access to secrets and a read and write GITHUB_TOKEN.
An attacker can induce both to act on attacker-controlled content from the pull request that triggered them. GitHub Security Lab calls this the pwn request.
Three primitives do the damage. Command injection interpolates attacker-controlled data, a branch name, a title, a comment, straight into a run step, so it lands unescaped inside a shell command and executes. Code injection through actions/github-script evaluates attacker input as JavaScript at runtime.
And cross-workflow privilege escalation lets a low-privilege workflow write untrusted data into an artifact or output, which a second, high-privilege workflow then reads and acts on with the maintainer's token. Neither workflow is exploitable alone.
The vulnerability exists because of how they connect, which is exactly why the scanners stay green: a SAST or DAST tool pattern-matches a single file, and each file here is valid, well-formed YAML doing exactly what it was told.
"A scanner sees a workflow. An attacker sees a four-step chain to a permanent credential," explains Warden.
There is no single line to flag, because no single line is wrong.
That is the worst version of a measurement failure, because a red light sends someone to look for a problem and a green light sends everyone home.
Cordyceps passed every check because no single workflow file was wrong, it was the composition that was exploitable.
See how to close that gap by governing what enters your build at the source, not just what passes the scan.
Close the Gap
One Pull Request, Persistent Write Access to Shipped Security Content
On Microsoft's Azure Sentinel repository, Novee showed that a comment on a pull request could run anonymous attacker code on Microsoft's CI and steal a non-expiring GitHub App key, confirmed by Microsoft's Security Response Center.
Sentinel is Microsoft's SIEM, and its Content Hub ships detection rules and automated playbooks directly into customer workspaces.
A stolen key there offers persistent write access to the security content thousands of organizations rely on to detect attacks, quietly weakened and shipped downstream as a trusted update.
Google's AI Agent Development Kit sample repository is a reference thousands of developers copy when building agents on Google Cloud. A single pull request could execute code in Google's CI and escalate to roles/owner on the associated Google Cloud project, permanent owner-level access, confirmed by Google.
Apache Doris had a comparable path to credential theft, confirmed and fixed by the Apache Security Team. Three organizations, one composition problem, no line of code that a scanner could point to.
Nobody Decided to Trust That Pull Request
The phrase that should stop an engineering leader is "trust boundary that no one audited." Someone configured a workflow to treat an outsider's input as if it came from a maintainer. No human made that call on purpose.
This risk accreted, one reasonable-looking commit at a time, and it
increases with AI-generated workflows, where the moment of decision may never be audited at all.
I have put AI tooling into production engineering work and measured what it changed, so I will say plainly that the leverage is real and I am not arguing to slow it down.
But Novee is explicit that agentic coding is the multiplier: AI tools generate CI/CD configuration quickly and reproduce the same insecure patterns, so one mistake compounds across potentially millions of repositories, emitted with confidence and no provenance signal.
The volume of workflow decisions an organization now absorbs has outrun a review process sized for human-speed output.
Our standard security systems aren't ready for this either. Cordyceps is not a CVE, so it never enters the enumeration model. Furthermore, NIST acknowledged in April 2026 that it can no longer enrich every CVE, with submissions up 263% since 2020. Risks are multiplying.
Fortunately, Novee found no evidence of exploitation in the wild, and the named vendors have hardened or patched. However, this is a proven, exploitable pattern, not one single specific breach, and it is largely unpatched by default across the industry.
Close the Boundary, Then Govern What Crosses It
The immediate fixes are worth doing now: 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 env variable rather than inlining it, default permissions to read-only, pin third-party actions to a commit SHA rather than a moving tag, and gate privileged workflows behind manual approval for first-time contributors.
Do all of that and you have closed today's problems, but not the class of problems. The next pattern will build from individually correct steps, and it will also pass the scan. AI-driven development is
widening this software supply chain governance gap, and it’s accelerating.
The durable control is to govern what your build can trust at the source, so the
components and workflows entering your pipeline come from a governed origin with verifiable provenance, built from source rather than trusted on faith.
A hijacked upstream that publishes a poisoned package must meet and fail a check at the point of ingestion. A human owns the trust boundaries. That ownership has to operate at the speed AI is now generating decisions, because manual review at the far end of the pipeline cannot catch up.
Cordyceps did not defeat anyone's security tools. It walked past them, because every individual piece worked exactly as designed. That is the measurement trap in its purest form: the number stayed green while the thing it was supposed to guarantee stopped being true, if it was ever true at all.
Those pipelines were not exposed because the scanners failed. They were exposed because passing the scan didn't mean they were governed. For a while, nobody went looking.
A green pipeline is not a governed one.
Find out what's really running through yours.
Sponsored and written by
ActiveState.
Comments have been disabled for this article.
<small>Source: Bleeping Computer</small>
