The GitHub Actions Attack Pattern Your CI Security Scanners Miss

Researchers have identified a new class of vulnerabilities in Continuous Integration/Continuous Deployment (CI/CD) pipelines, dubbed "Cordyceps," which can be exploited by attackers with a free GitHub account. These weaknesses, disclosed by Novee Security, bypass traditional security scanning tools because they exploit the composition of workflow interactions rather than flaws within individual files.

The Cordyceps vulnerabilities leverage specific GitHub Actions triggers, namely `pull_request_target` and `workflow_run`. Unlike the more common `pull_request` trigger, which runs in an untrusted context without access to repository secrets, these triggers execute within the context of the base repository. This grants them access to sensitive secrets and a read/write `GITHUB_TOKEN`, allowing attackers to manipulate the CI/CD process using code from a pull request.

Three primary attack methods enable these vulnerabilities. Command injection allows attackers to embed unescaped, attacker-controlled data directly into shell commands within a workflow step. Code injection, using tools like `actions/github-script`, evaluates attacker-provided JavaScript code at runtime. Finally, cross-workflow privilege escalation enables a less privileged workflow to write untrusted data to an artifact or output, which a second, more privileged workflow then processes using the maintainer's credentials.

Crucially, each individual workflow file in these scenarios is syntactically correct and performs its intended function. Security scanners, which typically analyze single files for known malicious patterns, fail to detect these composite attacks. The vulnerability lies in the chain of interactions between workflows, a detail that current scanning methodologies do not assess.

Novee Security's research scanned approximately 30,000 high-impact repositories across various ecosystems, including npm, PyPI, crates.io, and Go. They flagged 654 repositories and confirmed over 300 as fully exploitable. Affected projects included those from major organizations such as Microsoft, Google, Apache, Cloudflare, and the Python Software Foundation.

In one documented instance on Microsoft's Azure Sentinel repository, an attacker could steal a non-expiring GitHub App key by commenting on a pull request. This key provided persistent write access to Sentinel's Content Hub, which distributes detection rules and playbooks to thousands of organizations. Similarly, a pull request against Google's AI Agent Development Kit sample repository could lead to code execution within Google's CI and escalate privileges to "roles/owner" on the associated Google Cloud project. Apache Doris also experienced a comparable credential theft vulnerability.

The researchers emphasize that these risks are amplified by the increasing use of AI-generated code for CI/CD configurations. AI tools can rapidly produce workflows that replicate insecure patterns, potentially propagating errors across millions of repositories with a false sense of security. The sheer volume of automatically generated configurations now exceeds the capacity of manual review processes.

While Novee Security found no evidence of these specific vulnerabilities being exploited in the wild, and the affected vendors have since implemented patches, the underlying attack pattern remains largely unaddressed across the industry. The vulnerabilities are not assigned CVE identifiers, making them difficult to track and enumerate within standard security models.

To mitigate these risks, immediate steps include preferring the `pull_request` trigger over `pull_request_target` for untrusted contributions, avoiding checking out pull request head code within privileged workflows, and passing event data through quoted environment variables instead of inlining it. Additionally, setting default permissions to read-only, pinning third-party actions to specific commit SHAs rather than mutable tags, and requiring manual approval for privileged workflows from first-time contributors are recommended.

Beyond these immediate fixes, a more durable solution involves governing what build systems can trust at the source. This means ensuring that components and workflows entering a pipeline originate from a verified, governed source with traceable provenance. This approach aims to shift security from detection after the fact to prevention at the point of ingestion, ensuring that pipelines are not just passing scans but are truly governed.