A new class of CI/CD workflow weakness could allow attackers to use malicious pull requests to compromise software supply chains.
The weakness, dubbed Cordyceps, was disclosed by Elad Meged, founding engineer and security researcher at Novee. It affects how automated workflows handle untrusted pull request input across code repositories.
Pull requests are central to modern software development. They allow developers to propose changes, review code, run automated checks, and merge updates into a main branch. But when CI/CD workflows run with excessive privileges or process untrusted input without proper isolation, a pull request can become more than a code suggestion.
It can become an attack path.
Cordyceps shows that the danger often does not come from a single broken component. It comes from how trusted automation, secrets, tokens, comments, workflow triggers, and external contributors interact.
What Is Cordyceps?
Cordyceps is a class of supply chain weakness that affects CI/CD workflows around pull requests.
The issue appears when workflows process attacker-controlled pull request data while also holding elevated permissions, signing keys, access tokens, or other sensitive credentials.
In many repositories, CI/CD workflows need broad access to perform useful tasks. They may build code, run tests, publish packages, sign releases, update checks, comment on pull requests, or access cloud projects.
That access is powerful.
If an attacker can influence how those workflows run, they may be able to execute code, steal credentials, forge checks, bypass merge gates, publish malicious packages, or compromise downstream users.
The workflow may be doing exactly what it was configured to do. The vulnerability exists in the composition: untrusted input crosses a trust boundary that no one audited.
Why Pull Requests Are a Supply Chain Risk
Pull requests are designed to accept input from outside contributors, especially in open source projects.
That openness is a strength, but it creates risk when automation treats pull request content, comments, metadata, or branches as trusted.
Attackers can craft malicious pull requests that target:
- workflow triggers
- comments processed by automation
- branch names
- file paths
- build scripts
- test commands
- environment variables
- dependency manifests
- CI configuration
- generated artifacts
- bot commands
If a workflow reacts to these inputs with high privileges, the attacker may gain access to assets that should only be available to trusted maintainers.
This is especially dangerous because CI/CD systems often sit close to the release process.
What Novee Found
Novee said a single scan flagged 654 repositories as potentially exploitable through Cordyceps-style weaknesses.
Of those, around 300 were confirmed fully exploitable for outcomes such as:
- attacker-controlled code execution
- credential theft
- command injection
- privilege escalation
- supply chain compromise
- malicious package publishing
- forged CI checks
- merge gate bypass
- bot impersonation
- social engineering opportunities
The affected repositories reportedly included projects from major organizations as well as smaller teams.
This matters because software supply chain attacks scale. A weakness in one repository can impact every organization that consumes its code, packages, actions, or artifacts.
Examples of Impact
Novee reported several high-profile examples.
In Microsoft’s Azure Sentinel repository, the researchers found that a pull request comment could cause Microsoft’s CI environment to run attacker-controlled code and steal a non-expiring GitHub App key.
In Google’s AI Agent Development Kit, a pull request could reportedly run attacker code in Google’s CI and gain authenticated control over an associated Google Cloud project, including authority over a Google Cloud repository.
Novee also described zero-click pull request attacks involving Apache Doris, Cloudflare Workers SDK, and the Python Software Foundation’s Black project.
Microsoft and Google reportedly confirmed impact. Cloudflare and Apache applied hardening or fixes.
Novee stated that there is no evidence these workflow patterns were exploited broadly at scale, but the exposure shows why CI/CD workflow design needs more scrutiny.
Why CI/CD Workflows Are So Powerful
CI/CD workflows are not just automation scripts.
They often have access to:
- repository tokens
- cloud credentials
- package publishing secrets
- signing keys
- deployment permissions
- GitHub App keys
- artifact stores
- internal registries
- privileged bots
- production or staging environments
That means a vulnerable workflow can become a direct route from a pull request to sensitive infrastructure.
A malicious PR does not need to be merged to cause harm if the workflow runs before merge and has access to secrets or privileged actions.
This is the core problem: pre-merge automation often handles untrusted input while operating with too much trust.
“Workflow Code Is Code”
One of the most important lessons from Cordyceps is that workflow code must be treated like application code.
CI/CD configuration is often written in YAML, but it still controls execution, permissions, secrets, deployment paths, and trust boundaries.
Organizations often review application code carefully while treating workflow files as operational configuration.
That is a mistake.
A few lines of YAML can decide whether a pull request from an unknown contributor can trigger privileged automation.
Workflow files deserve the same review, threat modeling, testing, and ownership as production code.
Why AI Coding Agents May Make the Problem Worse
Meged warned that AI coding agents are scaling the problem.
AI tools can generate CI/CD configurations quickly, but they may also reproduce insecure patterns repeatedly.
If developers ask AI to create workflows and accept the output without understanding trust boundaries, the same mistakes can spread across many repositories.
This is especially risky because CI/CD security requires context.
A workflow that is safe for internal branches may be dangerous for public pull requests. A token that is harmless in a read-only job may be catastrophic in a publish job. A comment-triggered bot may be useful for maintainers but dangerous when anyone can invoke it.
AI-generated workflow code must be reviewed with the same care as human-written code.
Common Cordyceps Patterns
Cordyceps-style issues may appear in different ways depending on repository design.
Common risky patterns include:
- running untrusted pull request code with write permissions
- exposing secrets to workflows triggered by external contributors
- using
pull_request_targetunsafely - executing commands based on PR comments
- trusting branch names, file paths, or metadata
- using bot commands without author authorization checks
- allowing workflows to publish artifacts from untrusted code
- granting broad repository or organization tokens
- using long-lived non-expiring credentials
- mixing validation jobs with privileged deployment jobs
- treating CI-generated checks as trustworthy without protecting the workflow
The details vary, but the underlying issue is consistent: untrusted input gets too close to privileged automation.
Why Scanners May Miss It
Cordyceps can be difficult for traditional scanners to detect because each individual component may appear to work correctly.
The workflow triggers as configured. The token has the permissions it was assigned. The bot processes comments as designed. The build job runs normally.
The weakness only becomes visible when the entire flow is analyzed as a system.
Security teams need to ask:
- Who can trigger this workflow?
- What code does it execute?
- What permissions does it have?
- What secrets can it access?
- Can untrusted users influence commands?
- Can outputs from untrusted jobs affect trusted jobs?
- Can this workflow publish, sign, merge, or deploy anything?
- Can a pull request change files that the workflow later trusts?
This is composition risk, not only code risk.
What Attackers Could Do
If exploited, Cordyceps-style weaknesses could enable serious supply chain outcomes.
Attackers may be able to:
- steal GitHub tokens
- steal cloud credentials
- access package registry secrets
- publish malicious packages
- modify release artifacts
- forge successful CI checks
- bypass branch protection
- impersonate bots or maintainers
- inject malicious dependencies
- compromise cloud projects
- deploy malicious code
- access private repositories
- pivot into organization infrastructure
For open source projects, the impact can spread to downstream users. For enterprises, it can compromise internal build systems, deployment paths, and production environments.
Defensive Recommendations
Organizations should begin by inventorying workflows that run on untrusted input.
Key questions include:
- Which workflows run on pull requests from forks?
- Which workflows use
pull_request_target? - Which workflows process PR comments?
- Which workflows have write permissions?
- Which workflows access secrets?
- Which workflows publish packages or artifacts?
- Which workflows deploy to cloud environments?
- Which bots can be triggered by non-maintainers?
After identifying risky workflows, teams should reduce privileges and separate trust zones.
Recommended controls include:
- use least privilege for workflow tokens
- avoid exposing secrets to untrusted pull request jobs
- separate build/test jobs from publish/deploy jobs
- require maintainer approval before privileged workflows run
- avoid executing PR-controlled code in privileged contexts
- validate who issued PR comments before acting on them
- pin third-party actions to trusted commit SHAs
- require code review for workflow changes
- protect workflow files with CODEOWNERS
- rotate long-lived credentials
- use short-lived tokens where possible
- audit GitHub App permissions
- restrict package publishing workflows
- monitor workflow runs for unusual commands
The goal is to ensure that untrusted contributors cannot reach trusted automation directly.
Secure Handling of Pull Request Automation
Pull request automation should be designed around trust boundaries.
A safe pattern is to run untrusted PR code in a restricted job with no secrets and minimal permissions.
Privileged actions, such as publishing, signing, deployment, or writing to repositories, should only run after trusted maintainer approval and from trusted code.
Organizations should also avoid letting untrusted content control command execution.
For example, PR comments should not trigger powerful workflows unless the comment author is verified as a maintainer or approved contributor.
Even then, the workflow should carefully validate inputs.
Why Branch Protection Alone Is Not Enough
Branch protection is important, but it may not fully protect against CI/CD workflow abuse.
If attackers can forge CI checks, steal tokens, or influence privileged automation before merge, branch protection may be bypassed or weakened.
Branch protection should be combined with:
- protected workflow files
- restricted workflow permissions
- required reviews for CI changes
- safe token scopes
- approval gates for external contributors
- signed release processes
- artifact provenance
- monitored deployment workflows
Supply chain protection must cover the whole path from pull request to release.
Recommendations for CISOs
CISOs should treat CI/CD workflows as critical security assets.
Practical steps include:
- create an inventory of all CI/CD workflows
- classify workflows by privilege level
- identify workflows triggered by untrusted input
- review all workflows that access secrets
- enforce least privilege across CI/CD tokens
- require security review for workflow changes
- define ownership for workflow security
- include CI/CD in threat modeling
- monitor developer automation for abuse
- use trusted tooling to detect risky workflow patterns at scale
- train engineering teams on CI/CD trust boundaries
The key mindset shift is simple: workflow code is code, and it can be exploited like code.
Final Thoughts
Cordyceps shows how malicious pull requests can become a path into CI/CD workflows and software supply chains.
The issue is not one specific CVE or one broken vendor product. It is a class of configuration and trust-boundary weaknesses that can appear anywhere developers automate pull request handling.
A workflow may be “working as designed” and still be dangerous.
For defenders, the message is clear: review CI/CD workflows with the same rigor as application code. Identify where untrusted input meets privileged automation, reduce permissions, protect secrets, and require approval before high-risk jobs run.
In modern software supply chains, the pull request is not just a collaboration mechanism. It can also be an attack surface.
