The Cordyceps Exploits: Why Your CI/CD Pipelines Are Wide Open

For years, software security focused heavily on application code. We scanned for SQL injection, patched buffer overflows, and audited dependencies. Yet some of the most privileged code in any modern engineering organization has escaped this rigor.

That code is your CI/CD pipeline.

Security research firm Novee Security recently exposed a systemic class of workflow vulnerabilities codenamed Cordyceps. By scanning approximately 30,000 high-impact repositories across the npm, PyPI, crates, and Go ecosystems, researchers flagged 654 projects and confirmed that more than 300 were fully exploitable. The victims include tech giants and foundational open-source projects: Microsoft, Google, Apache, Cloudflare, and the Python Software Foundation.

The Cordyceps findings reveal a fundamental architectural blind spot. Developers widely treat GitHub Actions YAML files as passive configuration. In reality, they are active, highly privileged execution environments. When untrusted inputs cross trust boundaries within these pipelines, they allow unauthenticated external actors to hijack the build process, steal secrets, and poison downstream software releases.

Anatomy of a Cordyceps Chain

Traditional security scanners fail to catch Cordyceps because they look at single files in isolation. A static analysis tool sees a syntactically valid YAML file and moves on. The vulnerability only appears when you trace the flow of data across multiple workflows and trust boundaries.

An attacker needs nothing more than a free, anonymous GitHub account to exploit these chains. The attack typically follows a multi-step progression:

flowchart TD
    A[Untrusted PR or Comment] -->|Triggers| B(Low-Privilege Workflow)
    B -->|Injects Malicious Payload| C(Shared Artifact or Output)
    C -->|Consumed by| D(High-Privilege Workflow)
    D -->|Exposes| E[Secrets or Cloud Credentials]
    E -->|Attacker Gains| F[Full Repository or Cloud Control]

The real-world compromises documented by Novee show how devastating this pattern is in practice:

• Microsoft Azure Sentinel: An anonymous comment on a pull request executed code on Microsoft's CI infrastructure. This allowed the attacker to steal a non-expiring GitHub App key, granting write access to security detection content deployed directly to customer workspaces via the Azure Marketplace.
• Google's AI Agent Development Kit (adk-samples): A single malicious pull request executed code on Google's CI, granting the attacker the roles/owner role (the highest possible privilege) over the associated Google Cloud project.
• Apache Doris: Two zero-click attack paths allowed a comment on any PR, or a forked PR, to execute code and exfiltrate hard-coded CI credentials or a token with full write permissions across actions, contents, and packages.
• Cloudflare Workers SDK: A pull request with a specially crafted branch name triggered arbitrary command execution on Cloudflare's CI runners using the Wrangler CLI tool.
• Python Software Foundation's Black: The code formatter, which serves 130 million downloads a month, was vulnerable to a single pull request that could steal the project's automation token. An attacker could use that token to forge PR approvals and poison official Docker images.

All of these organizations have since applied patches and hardened their pipelines, but the underlying architectural patterns remain widespread.

The AI Boilerplate Multiplier

This issue is growing exponentially due to the rise of agentic coding. AI coding assistants are highly efficient at generating CI/CD configuration files, but they do so by training on existing public repositories.

If those public repositories contain insecure workflow patterns, the AI models learn and replicate them. Developers accept the AI-generated YAML without a second thought, pasting it into enterprise repositories. This creates a feedback loop that silently infects software pipelines at scale.

Developer Guide: Hardening Your Workflows

Securing your pipelines requires shifting your mental model. You must treat workflow files with the same security engineering principles you apply to application code.

Advertisement

Shadow GPS — know where it is, always Real-time GPS tracking for vehicles, gear and loved ones. No monthly contracts.

1. Stop Direct String Interpolation in Shell Scripts

The most common vector for command injection in GitHub Actions is placing GitHub context expressions directly inside a run step.

Consider this vulnerable pattern:

- name: Check PR Title
  run: |
    echo "Processing PR: ${{ github.event.pull_request.title }}"

If an attacker submits a PR titled test"; rm -rf /; echo ", the runner evaluates the expression and executes the malicious commands.

To fix this, always map the context expression to an environment variable. Environment variables are treated as data, not executable code, preventing command injection:

- name: Check PR Title Securely
  env:
    PR_TITLE: ${{ github.event.pull_request.title }}
  run: |
    echo "Processing PR: $PR_TITLE"

2. Enforce Explicit, Minimal Token Permissions

By default, GitHub Actions workflows often run with broad write permissions. If an attacker compromises a runner, they inherit those permissions.

You should explicitly define the minimum permissions required for the GITHUB_TOKEN at the workflow or job level. Start by revoking all permissions and only grant what is strictly necessary:

permissions:
  contents: read
  issues: none
  pull-requests: none

If a job only needs to check out code, contents: read is sufficient. Never leave the default permissions set to write-all.

3. Isolate Untrusted Code in pull_request_target

The pull_request trigger runs in the context of the fork, meaning it has no access to repository secrets and runs with a read-only token. To bypass this, developers often use pull_request_target, which runs in the context of the base repository and has access to secrets.

Using pull_request_target to check out and run untrusted code from a PR is highly dangerous. If you must use it, ensure you never run build scripts, tests, or linters from the incoming PR branch. Only run tools defined in your master branch against static data.

The Verdict

The Cordyceps research is a wake-up call. It proves that the boundary between untrusted external input and highly privileged internal environments is incredibly thin in modern CI/CD setups.

Treating YAML files as passive configuration is a recipe for supply-chain disaster. If your organization relies on GitHub Actions or similar CI/CD platforms, you must audit your workflow files immediately. Transition to environment variables for all dynamic inputs, enforce the principle of least privilege on your automation tokens, and treat pipeline security as a core engineering discipline.