A Critical Vulnerability in GitHub Actions Exposes Thousands of Repositories to Attack
A recent discovery by researchers at Novee Security has shed light on a critical vulnerability in GitHub Actions that can leave thousands of repositories exposed to attack. Dubbed “Cordyceps,” this weakness allows an attacker with a free GitHub account to induce both trusted and untrusted workflows to act on their behalf, resulting in the execution of malicious code. The alarming part? This vulnerability was present in 300 out of 654 affected repositories, including those published by major organizations such as Microsoft, Google, and Apache.
What’s remarkable about this attack pattern is that it doesn’t involve a single line of code or a specific file. Instead, it relies on the composition of multiple workflows and their interactions to achieve its goal. GitHub Actions workflows typically run in two different contexts: when triggered by a pull request (pull_request), they operate in an untrusted context with limited privileges, while workflows triggered by pull_request_target or workflow_run run in the context of the base repository with access to secrets and higher privileges.
An attacker can manipulate these interactions to execute malicious code, leveraging three specific primitives: command injection, which inserts attacker-controlled data into a shell command; code injection through actions/github-script, which evaluates attacker input as JavaScript at runtime; and cross-workflow privilege escalation, where a low-privilege workflow writes untrusted data that’s later read by a high-privilege workflow. The key takeaway is that neither workflow alone is exploitable, but their interaction creates the vulnerability.
The problem lies in how these workflows connect, which allows scanners to miss this attack pattern entirely. SAST and DAST tools typically look for specific vulnerabilities within individual files, whereas Cordyceps relies on the composition of multiple workflows. As a result, a green pipeline can mask a serious security risk.
The implications are far-reaching. Novee Security demonstrated that a single pull request could lead to persistent write access to shipped security content in Microsoft’s Azure Sentinel repository, while another example showed how an attacker could escalate privileges to permanent owner-level access on Google Cloud projects. In both cases, the vulnerability was present despite the pipelines reporting healthy results.
The takeaway from this discovery is clear: governing what enters your build at the source, rather than just relying on scanners to detect vulnerabilities, is crucial for maintaining pipeline security. As AI-generated workflows become increasingly prevalent, it’s essential to recognize that trust boundaries must be audited and regularly reviewed to prevent such risks from accreting over time.
Ultimately, this vulnerability serves as a reminder that securing CI/CD pipelines requires more than just scanning individual files or code snippets. It demands a comprehensive understanding of how different components interact and the ability to detect vulnerabilities in complex workflows. By acknowledging these complexities and implementing proactive measures, organizations can reduce their exposure to such attacks and ensure the integrity of their software development processes.
Source: Bleeping Computer — 2026-07-07