Cordyceps CI/CD Flaws: How a Free Account Is Enough to Hijack 300+ High-Impact Repositories and Compromise the Open-Source Supply Chain + Video

Listen to this Post

Featured Image

Introduction:

The software supply chain has long been a prime target for sophisticated attackers, but a newly uncovered class of CI/CD workflow weaknesses—codenamed Cordyceps—reveals a chilling reality: a free GitHub account and a single pull request comment are all it takes to execute arbitrary code on the build systems of Microsoft, Google, Apache, and Cloudflare. Discovered by Novee Security, this “critical exploitable pattern” stems from weak CI/CD configurations that grant untrusted pull requests (PRs) more permissions than they should have, allowing unauthenticated users to forge approvals, push malicious code, or steal non-expiring credentials. With over 300 high-impact repositories found to be fully exploitable, the Cordyceps vulnerability underscores a fundamental flaw in how the industry approaches CI/CD security—where every individual component works as designed, but their composition creates a trust boundary that no one audited.

Learning Objectives:

  • Understand the technical mechanics of Cordyceps-style CI/CD workflow hijacking and how untrusted PRs can cross trust boundaries.
  • Identify misconfigurations in GitHub Actions, Azure Pipelines, and other CI/CD platforms that enable privilege escalation and credential theft.
  • Implement practical mitigation strategies, including least-privilege principles, environment isolation, and strict PR validation.
  • Apply Linux, Windows, and cloud-1ative commands to audit, harden, and monitor CI/CD pipelines against supply chain attacks.
  • Recognize the broader implications of agentic coding and AI-generated code on the proliferation of CI/CD vulnerabilities.

You Should Know:

  1. The Anatomy of Cordyceps: How Untrusted PRs Become Attack Vectors

At its core, the Cordyceps vulnerability exploits a dangerous assumption: that pull requests originating from forks or external contributors can be treated as trusted entities once they trigger a CI/CD workflow. In practice, many organizations configure their GitHub Actions or Azure Pipelines to automatically execute workflows on PR events—often with write permissions to the repository, access to secrets, or even the ability to approve subsequent PRs.

Step‑by‑step guide explaining what this does and how to use it:

  1. Reconnaissance: An attacker identifies a target repository that uses CI/CD workflows triggered by `pull_request` events. Tools like `gh api` or GitHub’s REST API can list workflow files:
    gh api repos/{owner}/{repo}/actions/workflows --jq '.workflows[].path'
    
  2. Crafted PR Submission: The attacker submits a pull request from a forked branch. The PR includes a malicious payload embedded in the branch name, commit message, or PR comment—bypassing many scanners because the payload is not in the code diff itself.
  3. Workflow Trigger: The CI/CD runner automatically executes the workflow. If the workflow uses `pull_request_target` (which grants write permissions) or references secrets, the attacker’s payload runs in the context of the target repository.
  4. Credential Exfiltration: The attacker’s code steals non-expiring GitHub App keys, automation tokens, or hard-coded CI credentials, which are then used to approve pull requests, push code, or pivot to downstream dependencies.
  5. Persistence and Propagation: With stolen tokens, the attacker can modify workflow files, inject backdoors, or compromise artifacts published to package registries—affecting all consumers of the compromised project.

Linux Command to Detect Overly Permissive Workflows:

 Find all workflow files in a repository
find .github/workflows -1ame ".yml" -exec grep -l "pull_request_target|persist-credentials: false|secrets:" {} \;

Windows PowerShell Equivalent:

Get-ChildItem -Path ..github\workflows\ -Filter .yml | Select-String -Pattern "pull_request_target|persist-credentials|secrets:"

2. Real-World Exploits: Microsoft, Google, Apache, and Cloudflare

Novee Security’s research uncovered concrete, zero-click attack vectors across some of the world’s largest technology organizations. These case studies illustrate the diversity of Cordyceps-style weaknesses and the severity of their impact.

Step‑by‑step guide explaining what this does and how to use it:

  • Microsoft Azure Sentinel: A single comment on a PR could run anonymous attacker code on Microsoft’s CI infrastructure, stealing a non-expiring GitHub App key that granted extensive privileges. This meant an external contributor could effectively become a repository administrator without any approval.
  • Google AI Agent Development Kit (“adk-samples”): A PR triggered attacker code on Google’s CI, granting complete authority over a Google Cloud repository. The attacker could then modify cloud resources, exfiltrate data, or deploy malicious artifacts.
  • Apache Doris: Two zero-click attacks allowed a single comment on any PR—or a forked PR—to run attacker code and exfiltrate hard-coded CI credentials or a token with full write permissions.
  • Cloudflare Workers SDK: A crafted branch name in a PR could execute arbitrary commands on Cloudflare’s CI runners, compromising the build environment.
  • Python Software Foundation’s Black: A single pull request from anyone could execute attacker code on Black’s build systems, steal the automation token, and then use that token to approve pull requests—effectively giving the attacker control over the project’s merge process.

Mitigation Configuration for GitHub Actions:

 Example: Restrict PR workflows to read-only permissions
on:
pull_request:
types: [opened, synchronize]
permissions:
contents: read
pull-requests: read
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
persist-credentials: false
- run: make test
  1. The Trust Boundary Problem: Why Scanners Miss Cordyceps

Novee Security emphasizes that Cordyceps is not a traditional vulnerability in any single piece of code; rather, it is a “compositional” flaw—every individual component works as designed, but the interaction between untrusted data (the PR) and a trusted environment (the CI/CD runner) creates an unauthenticated trust boundary. This is why traditional SAST, DAST, and dependency scanners fail to detect Cordyceps: they audit code, not the orchestration logic that determines when and how that code runs.

Step‑by‑step guide explaining what this does and how to use it:

  1. Audit Workflow Triggers: Review all workflow files and identify which events trigger them. Pay special attention to pull_request_target, workflow_dispatch, and repository_dispatch, as these often run with elevated privileges.
  2. Map Data Flow: Trace how data from the PR (branch name, commit message, PR title, comment body) flows into workflow steps. Any step that interpolates this data into shell commands, scripts, or environment variables is a potential injection point.
  3. Test with Safe Payloads: Create a test PR with a benign payload (e.g., echo "test") and observe whether it executes in the workflow’s context. If it does, the pipeline is vulnerable.
  4. Implement Explicit Trust Boundaries: Never allow untrusted PR data to influence privileged operations. Use separate workflows for PR validation (read-only) and for merging/deployment (triggered only after manual approval or from trusted branches).

Linux Command to Monitor CI/CD Logs for Suspicious Activity:

 Monitor GitHub Actions logs for unexpected shell commands
grep -r "run:.\${{" .github/workflows/ | grep -v "github.event" | grep -v "env."

Windows PowerShell to Check for Hard-Coded Secrets:

Select-String -Path ..github\workflows.yml -Pattern "secret:|token:|password:" | Format-Table
  1. Hardening CI/CD Pipelines: Least Privilege and Environment Isolation

The most effective defense against Cordyceps-style attacks is to apply the principle of least privilege at every layer of the CI/CD pipeline. This means workflows triggered by untrusted PRs should never have write access to the repository, access to production secrets, or the ability to modify other workflows.

Step‑by‑step guide explaining what this does and how to use it:

  1. Use Read-Only Permissions for PR Workflows: Set default permissions to `contents: read` and `pull-requests: read` for all `pull_request` events. Override only for trusted branches.
  2. Separate Build and Deploy Stages: Run tests and static analysis in a low-privilege environment. Only after a PR is approved and merged to a protected branch should the deployment workflow execute with higher permissions.
  3. Rotate and Scope Secrets: Use GitHub’s environment protection rules to limit secrets to specific branches or environments. Avoid using non-expiring tokens—prefer short-lived tokens that are automatically rotated.
  4. Enforce Branch Protection Rules: Require status checks to pass before merging, and restrict who can approve PRs. Combine this with required reviews from code owners.
  5. Audit Third-Party Actions: Many workflows use community actions that may introduce vulnerabilities. Pin actions to specific SHA hashes rather than version tags, and review the source code of any action that processes PR data.

GitHub CLI Command to List Workflows with Write Permissions:

gh api repos/{owner}/{repo}/actions/workflows --jq '.workflows[] | select(.permissions.write == true) | .name'

Azure DevOps PowerShell to Audit Pipeline Permissions:

az pipelines show --id {pipeline-id} --query "authorization" | ConvertFrom-Json
  1. The Exponential Risk of Agentic Coding and AI-Generated Workflows

Elad Meged of Novee Security warns that the rise of agentic coding—where AI agents automatically generate and modify CI/CD configurations—is accelerating the proliferation of Cordyceps-style vulnerabilities. These agents often copy patterns from public repositories, replicating insecure configurations at scale without human oversight.

Step‑by‑step guide explaining what this does and how to use it:

  1. Review AI-Generated Configurations: Treat any AI-generated workflow file as a draft that requires thorough human review. Never deploy AI-suggested YAML without understanding each permission and trigger.
  2. Implement Automated Policy as Code: Use tools like Open Policy Agent (OPA) or Checkov to enforce security policies on workflow files before they are committed. For example, reject any workflow that uses `pull_request_target` without explicit approval.
  3. Monitor for Anomalous PR Activity: Set up alerts for PRs that trigger workflows with elevated permissions, especially from first-time contributors or forked repositories.
  4. Educate Development Teams: Conduct regular training sessions on CI/CD security, emphasizing that PRs are untrusted until proven otherwise. Include real-world examples like the Azure Sentinel and Google ADK cases.
  5. Adopt a “Zero Trust” Mindset: Never assume that a workflow is safe just because it passed a scan. Continuously validate that the composition of triggers, permissions, and data flows does not create an exploitable trust boundary.

Checkov Policy Example to Block Dangerous Triggers:

 Custom Checkov policy (YAML)
metadata:
name: "Cordyceps Prevention - No pull_request_target"
category: "CI/CD Security"
definition:
or:
- not:
contains:
- "pull_request_target"

What Undercode Say:

  • Key Takeaway 1: Cordyceps is not a bug in any single tool but a systemic failure in how the industry composes CI/CD workflows. The vulnerability exists in the “glue” between components, making it invisible to most scanners.
  • Key Takeaway 2: A free GitHub account and a single PR comment are sufficient to compromise repositories at Microsoft, Google, Apache, and Cloudflare—demonstrating that even the most security-conscious organizations are vulnerable to misconfigured automation.

Analysis: The Cordyceps findings represent a watershed moment for CI/CD security. For years, the industry has focused on securing code and dependencies, but the orchestration layer—the workflows that build, test, and deploy that code—has remained an afterthought. Novee’s research proves that attackers are already exploiting this gap, and the responsible disclosures to Microsoft, Google, Cloudflare, Apache, and Python highlight the urgent need for a paradigm shift. Organizations must treat CI/CD pipelines as critical infrastructure, applying the same rigorous security controls—least privilege, audit logging, and zero-trust networking—that they use for production environments. The rise of agentic coding only amplifies this risk, as AI agents replicate insecure patterns faster than humans can review them. The path forward requires not just patching individual workflows but rethinking the fundamental trust model of open-source collaboration.

Prediction:

  • -1 The proliferation of Cordyceps-style vulnerabilities will continue to grow as AI-generated code and workflows become ubiquitous, with attackers increasingly targeting CI/CD pipelines as the most efficient entry point for supply chain compromise.
  • -1 Without widespread adoption of policy-as-code and automated security gates, the number of exploitable repositories will likely exceed 1,000 within the next 12 months, as more organizations adopt GitHub Actions and similar platforms without adequate security reviews.
  • +1 The responsible disclosure and public analysis of Cordyceps will drive significant investment in CI/CD security tooling, leading to new classes of static analysis and runtime protection specifically designed to detect compositional flaws.
  • +1 Major cloud providers and CI/CD platforms will introduce built-in safeguards—such as automatic permission scoping for PR workflows and AI-assisted configuration hardening—reducing the attack surface for future Cordyceps-like vulnerabilities.
  • -1 The barrier to entry for supply chain attacks will remain low, as the core issue—untrusted data crossing trust boundaries—is a design pattern repeated across thousands of repositories, making it a persistent challenge that cannot be solved by patches alone.

▶️ Related Video (68% Match):

🎯Let’s Practice For Free:

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

IT/Security Reporter URL:

Reported By: Mohit Hackernews – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky