In June 2026, security research firm Novee Security published findings from a scan of approximately 30,000 high-impact GitHub repositories. The results were striking: 654 repositories were flagged in a single automated scan, and more than 300 were confirmed to be fully exploitable by any attacker with a free GitHub account. The vulnerability class has been named Cordyceps, after the parasitic fungus that hijacks the nervous system of its host organism to serve the parasite's purposes. Confirmed affected repositories belonged to Microsoft, Google, Apache, Cloudflare, and the Python Software Foundation, among many others. No evidence of active exploitation at scale had been found at the time of publication, but the attack pattern is simple and the vulnerability class is structural rather than incidental.
The Cordyceps fungus infects insects, takes control of their behaviour from the inside, and uses the host's own body to spread the parasite further. Novee's choice of name is deliberate: the vulnerability class they identified allows an attacker to inject themselves into a trusted software development process and use that process's own permissions and infrastructure to execute attacker-controlled code, steal credentials, or compromise the resulting software supply chain. The host, in this case, is the legitimate continuous integration pipeline of an organisation's own GitHub repository.
The attack surface is the pull request workflow that underlies collaborative development on GitHub. Pull requests are the mechanism by which external contributors propose changes to a repository. Most organisations have configured their CI/CD pipelines to run automated tests, builds, and checks when a pull request is opened, before a human reviewer approves the change. The Cordyceps vulnerability class exploits cases where these automated workflows run with more trust and permission than the pull request that triggered them deserves.
The fundamental problem Novee identified is that GitHub Actions workflows in affected repositories grant pull request events permissions that should be reserved for trusted code on the default branch. When a pull request from an untrusted contributor triggers a workflow, that workflow should operate with minimal permissions: it can run tests against the proposed code, but it should not be able to access secrets, push to the repository, or authenticate to external cloud services. In many of the affected repositories, this separation had not been enforced.
The specific vulnerability types Novee documented include command injection, where attacker-controlled strings from the pull request are interpolated into shell commands that run in the CI environment; broken authentication logic, where the workflow incorrectly trusts the identity of the pull request actor; artifact poisoning chains, where the output of one low-privilege workflow step is consumed by a subsequent high-privilege step without validation; and privilege escalation in GitHub Actions itself, where misconfigured workflow permissions allow a pull request to acquire tokens that should only be available to repository maintainers.
Each of these vulnerability types is independently exploitable. The most dangerous findings in Novee's research were the multi-step exploit chains in which no single step appears dangerous when examined in isolation, but the composition of steps creates a critical path from untrusted pull request to complete repository compromise.
Novee's documentation of the exploit chains reveals the structural elegance of the attack. An untrusted pull request triggers a low-privilege workflow. That workflow's output, perhaps a build artefact or a cached result, flows into a second workflow that runs with higher privileges. The second workflow consumes the output without validating that it comes from a trusted source. The high-privilege token that the second workflow uses then authenticates to an external cloud service, such as Google Cloud Platform, with an IAM role that grants administrative access.
From the attacker's perspective, every step of this chain uses the repository's own infrastructure in a way that individual workflow operators might consider normal. The low-privilege workflow running on a pull request is expected behaviour. The artefact being passed between workflow stages is expected behaviour. The authentication to the cloud service is expected behaviour. The danger lies in the implicit trust that each step extends to the output of the previous step, without verifying that the chain originated from a trusted source.
Novee describes these cases as vulnerabilities that exist only in the composition. A developer auditing any individual component of the pipeline would see nothing unusual. Only a reviewer who traces the complete path from pull request through to cloud authentication would recognise that an untrusted contributor can reach the final privileged step.
Microsoft's Azure Sentinel repository is one of the most visible examples Novee disclosed. Azure Sentinel is Microsoft's cloud-native security information and event management system, used by enterprise security teams worldwide. Novee found that a comment on a pull request opened against the Azure Sentinel repository could trigger attacker-controlled code execution on Microsoft's CI infrastructure. That code execution could then steal a non-expiring GitHub App key used by Microsoft's CI systems.
A non-expiring GitHub App key is a significant prize. Unlike short-lived tokens that rotate automatically, an App key persists indefinitely unless explicitly revoked. An attacker who acquired this key would retain access to Microsoft's CI infrastructure for as long as the key remained valid, regardless of whether the original pull request was eventually rejected or the repository was updated. The persistence of the access, not just its scope, is what makes the finding particularly serious.
Microsoft confirmed the finding and implemented fixes. The vulnerability existed in the composition of workflow steps and permissions, not in any individual line of code that a standard security review would have flagged as dangerous.
The Google finding involves the adk-samples repository, which is the sample code repository for Google's AI Agent Development Kit. A pull request opened against this repository could, under the vulnerable configuration, cause attacker-controlled code to execute on Google's CI infrastructure. From there, the exploit chain reached authenticated control over the Google Cloud project associated with the repository, granting what Novee describes as full authority over a Google Cloud repository.
Google Cloud project ownership is a high-value access level. A project owner can modify IAM policies, access stored credentials and secrets, spin up or tear down cloud resources, and access any data stored in services within the project. The scope of what an attacker could do with this access would depend on what the specific Google Cloud project contained, but the access level itself represents a complete compromise of the associated cloud environment.
Google confirmed the finding and fixed the vulnerability. As with the Microsoft case, the issue was structural: a sequence of workflow steps that, individually, appeared reasonable but collectively created a path from an untrusted contributor to administrative cloud access.
The breadth of Novee's scan is as significant as the specific findings at Microsoft and Google. Scanning approximately 30,000 high-impact repositories and finding more than 300 fully exploitable is a hit rate that suggests the vulnerability class is common rather than exceptional. The 654 repositories flagged in a single scan indicates that the patterns Novee identified are reproducible at scale with automated tooling.
The organisations affected extend beyond the named examples. Apache Software Foundation repositories were among those affected, meaning the vulnerability class reached the CI pipelines of the open-source projects whose outputs are embedded in an enormous proportion of the world's software infrastructure. Cloudflare, which operates infrastructure that handles a substantial share of global internet traffic, also had affected repositories. The Python Software Foundation, which maintains the CPython interpreter and the PyPI package registry, was similarly included.
The supply chain implications are material. A CI pipeline that an attacker can write to is a CI pipeline that can produce compromised software artefacts. Code signed and published by an affected organisation's CI system, after an attacker has had write access to that system, cannot be trusted to be what it appears. The downstream effect on users of software built on affected repositories is a secondary risk that extends well beyond the organisations directly targeted.
One of the most operationally significant aspects of the Cordyceps vulnerability class is its accessibility. Exploiting the affected repositories requires no existing relationship with the target organisation, no stolen credentials, and no inside knowledge of the repository's internal structure. A free GitHub account is sufficient to open a pull request against any public repository, and opening a pull request is all the initial trigger the exploit chain requires.
This is qualitatively different from vulnerabilities that require prior authentication, physical access, or exploitation of a separate vulnerability to reach the target. The Cordyceps attack surface is permanently exposed to anyone with internet access and a few minutes to create a GitHub account. The barrier is not technical but motivational: an attacker who identifies a target repository and crafts a pull request with the right characteristics gains access to the CI infrastructure as a direct consequence of a normal development workflow.
Understanding your organisation's attack surface in this context means acknowledging that any public repository whose CI/CD configuration has not been reviewed for pull request permission boundaries is potentially exposed to this class of attack.
Novee confirmed to Dark Reading that among the vendors which implemented fixes, no evidence of workflow patterns being exploited was found. The research team described the findings as a systemic class of vulnerability that had not yet been weaponised at scale. This is meaningful context, but it should be interpreted carefully. The absence of observed exploitation is not equivalent to the absence of exploitation: sophisticated attackers who have discovered and used this technique would have strong reasons to keep their access quiet rather than triggering detection by engaging in obvious malicious activity.
The attack pattern also does not require persistent access to be valuable. An attacker who uses a pull request to steal a long-lived credential, like the non-expiring GitHub App key found in the Microsoft case, can do so in a single interaction and then use the credential independently. There may be no ongoing anomaly in CI logs to detect after the credential has been taken.
The Cordyceps findings expose a structural problem in how trust boundaries are defined and enforced in modern CI/CD pipelines. GitHub Actions, the pipeline infrastructure involved in most of the affected repositories, has the technical controls to enforce minimal permissions on workflows triggered by pull requests. The pull_request event type in GitHub Actions runs with restricted permissions by default, while the pull_request_target event type runs in the context of the base repository and has access to secrets. The latter is the dangerous configuration and is the one Novee found exploitable.
The problem is that pull_request_target was specifically introduced to allow CI pipelines to post status checks and comments on pull requests from external contributors, a common requirement. Many repositories adopted it for this purpose without recognising that the event type changes the trust model of everything the workflow does subsequently. The Cordyceps vulnerability class is therefore partly a documentation and awareness failure: GitHub provides the tools to enforce trust boundaries, but the implications of different event types are not always understood by the developers configuring the workflows.
The first step is auditing all GitHub Actions workflow files in your repositories for uses of the pull_request_target event type. Any workflow using this event type should be reviewed to confirm that it does not execute code from the pull request itself and does not pass untrusted pull request data into subsequent steps that have elevated permissions or access to secrets. The GitHub Actions security hardening documentation provides specific guidance on safe uses of this event type.
The second step is enforcing least privilege at the workflow level. Every workflow should declare only the permissions it genuinely requires, using the permissions block in the workflow YAML. The default permission model for new repositories in GitHub's enterprise settings can be configured to require explicit permission declarations rather than inheriting a broad default. Reviewing existing workflows against the permissions they actually use is often the fastest way to identify configurations that grant more authority than needed.
For repositories that accept pull requests from external contributors, the safest configuration separates untrusted code execution from privileged operations entirely. Code from a pull request should run in an isolated environment with no access to repository secrets, and any privileged operations such as publishing artefacts or posting status checks should run in a separate workflow triggered by a maintainer action after the pull request has been reviewed. Monitoring for indicators of compromise in CI logs, particularly unexpected outbound network connections or credential use patterns, is the detection complement to these preventive controls.
Cordyceps is a class of CI/CD pipeline vulnerabilities discovered by Novee Security through a scan of approximately 30,000 high-impact GitHub repositories. The name refers to the parasitic fungus that hijacks its host's behaviour. The vulnerability class allows an attacker with only a free GitHub account to exploit misconfigured GitHub Actions workflows by opening a pull request, triggering attacker-controlled code execution on the target organisation's CI infrastructure, and potentially stealing credentials or compromising published software artefacts.
Novee confirmed findings at Microsoft, Google, Apache, Cloudflare, and the Python Software Foundation, among many others. More than 300 repositories across thousands of organisations were confirmed fully exploitable. Novee coordinated disclosure with affected organisations, and fixes have been confirmed at dozens of them. No specific list of all affected repositories has been published to avoid providing a target directory to potential attackers.
No. Exploiting a vulnerable Cordyceps repository requires only a free GitHub account and the ability to open a pull request. No prior access to the repository, no stolen credentials, and no membership in the target organisation is required. This makes the attack surface permanently exposed to any motivated actor who can identify a vulnerable repository configuration.
The pull_request event type runs workflows in the context of the pull request branch with minimal permissions and no access to repository secrets. The pull_request_target event type runs workflows in the context of the base repository, with access to secrets and elevated permissions. The latter was designed to allow CI systems to post status checks on pull requests from external contributors, but it changes the trust model of the entire workflow. Cordyceps exploits repositories where pull_request_target is used in ways that allow untrusted pull request data to flow into privileged workflow steps.
Novee reported no evidence of the specific repositories they found being exploited broadly at scale before the fixes were applied. However, the absence of detected exploitation does not guarantee the absence of exploitation: sophisticated actors who discovered this technique independently would have reasons to use it quietly and avoid triggering detection. The attack pattern also lends itself to single-interaction credential theft that might leave no persistent anomaly in CI logs.
Start with repositories that publish software artefacts consumed by other projects or systems, because these have the highest supply chain impact if compromised. Then prioritise repositories with access to cloud infrastructure credentials or deployment pipelines. Within those repositories, search workflow YAML files for pull_request_target as the triggering event type and review all workflows that use it. Most CI/CD scanning tools now include checks for Cordyceps-style misconfigurations, and running one of these scans across your repository inventory will give you an ordered list of findings to work through.
Cordyceps primarily targets public repositories because private repositories restrict who can open pull requests. However, private repositories that grant external collaborator access to contributors who are not fully trusted also have an exposed pull request attack surface. If an organisation's workflows in public repositories share credentials or cloud access with private repository infrastructure, a successful Cordyceps exploit on the public repository could serve as a stepping stone to private resources. The complete audit should cover both public and private repositories where external contributions are possible.
Incidents like this one rarely announce themselves through official channels first. Indicators of active exploitation, compromised infrastructure, and stolen credentials circulate in closed forums and private channels well before any public advisory reaches your security team. By the time a vulnerability makes it into a published report, organisations without early visibility are already operating behind the curve.
Defendis gives your security team that early visibility. We monitor the dark web, underground forums, and threat actor channels so your team receives relevant intelligence before it becomes breaking news, with context about emerging threats matched against your organisation's exposure, without requiring your analysts to spend time in places they should not have to go.
