Skip to content
Tech News
← Back to articles

The GitHub Actions Attack Pattern Your CI Security Scanners Miss

read original more articles

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, Google, Apache, Cloudflare, and the Python Software Foundation, and the entry requirement for an attacker is a free GitHub account. No org membership, no elevated privileges.

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.

... continue reading