Cordyceps: Defending Against Malicious Pull Requests in CI/CD

The “Cordyceps” research campaign has uncovered a widespread threat targeting automated developer workflows across major open-source ecosystems. According to Dark Reading, this campaign leverages weaknesses in Continuous Integration and Continuous Deployment (CI/CD) pipelines to execute a Supply Chain Attack. By submitting specifically crafted pull requests, threat actors can manipulate the automation logic of a repository to gain unauthorized access to sensitive data or internal infrastructure.

Technical Analysis of Cordyceps Attack Vectors

The primary vector for this campaign involves exploiting the configuration of GitHub Actions, the automation platform integrated into GitHub. Attackers focus on workflows triggered by external contributions, utilizing a technique often referred to as “pwn-requests.” This occurs when a project’s automation is configured to run tests, linting, or building processes on every incoming pull request without sufficient isolation or manual oversight.

GitHub Actions pull_request_target security risks

The Cordyceps campaign specifically exploits the pull_request_target event. Unlike the standard pull_request trigger, which runs in a restricted context, pull_request_target runs in the context of the base repository. This provides the workflow with access to repository secrets and a GITHUB_TOKEN with write permissions. If the workflow is configured to check out the code from the incoming malicious fork and execute it—such as running a build script provided by the attacker—it leads to an RCE scenario within the CI/CD runner.

Researchers identified several high-profile targets affected by these configurations, including Microsoft’s Azure Sentinel, Google’s AI Agent Development Kit, the Apache Doris analytics database, the Cloudflare Workers SDK, and the Python Software Foundation’s Black formatter. In these instances, the workflow would automatically execute code from the untrusted pull request, allowing the attacker to exfiltrate environment variables, such as API keys and cloud provider credentials, to a remote C2 server.

Potential for Lateral Movement and Persistence

Successful exploitation of a CI/CD runner is rarely the end of an attack. Once an attacker gains a foothold in the build environment, they can attempt Lateral Movement to access other parts of the development infrastructure. This could include modifying build artifacts, poisoning software packages before they are signed and distributed, or accessing private internal repositories. For a SOC team, these incidents are difficult to distinguish from legitimate developer activity because the malicious actions are embedded within the standard contribution workflow.

While no specific CVE identifier has been assigned to the Cordyceps campaign itself, the threat stems from the architectural misuse of powerful CI/CD features. These incidents highlight that even when software is free of traditional vulnerabilities, the processes used to build and test that software can be turned against the organization. This campaign is representative of activities often associated with an APT targeting the software supply chain, where the goal is to compromise downstream users by infecting the source.

How to detect Cordyceps malicious pull requests

Organizations must implement proactive monitoring to identify and block these attacks. Detection strategies should focus on identifying anomalous behavior within CI/CD logs. Security teams should look for IoC signatures such as unauthorized outbound network requests during the build phase or shell scripts attempting to print environment variables to the console in base64 format. Implementing EDR solutions on self-hosted runners can also provide visibility into the processes spawned during a build, allowing for the detection of unauthorized binary execution.

Mitigation and Pipeline Hardening

To effectively mitigate CI/CD pipeline supply chain attacks, security teams should prioritize the following defensive measures:

• Restrict Trigger Usage: Avoid using pull_request_target for workflows that involve building or testing code from untrusted forks. Use the standard pull_request trigger whenever possible.
• Enforce Manual Approvals: Configure GitHub settings to require manual approval from a maintainer before any CI/CD workflow is triggered for first-time or outside contributors.
• Least Privilege Tokens: Ensure that the GITHUB_TOKEN used in workflows has the minimum permissions required. Explicitly set permissions to ‘read-only’ in the workflow YAML file unless ‘write’ is strictly necessary.
• Secret Management: Do not pass secrets to any build step that executes untrusted code. Use environment-specific secrets that are only accessible to protected branches.

Mapping these threats to the MITRE ATT&CK framework—specifically under ‘Exploitation of Software Discovery’ and ‘Supply Chain Compromise’—allows organizations to better understand the attacker’s path. Ultimately, a Zero Trust approach must be applied to all external contributions, ensuring that no code is executed in a privileged environment until it has been verified and approved by a trusted maintainer.