Cordyceps: A Free GitHub Account Is All It Takes to Hijack CI/CD Pipelines at Microsoft, Google, Apache, and Cloudflare — 300+ Repos Confirmed Exploitable

Sources: Novee Security primary research (Elad Meged) · The Hacker News · SecurityWeek · Dark Reading · Hackread · CybersecurityNews · GBHackers · Cyberpress · AI Weekly | Vulnerability name: Cordyceps | Discovered by: Novee Security — Elad Meged, Founding Engineer | Repositories scanned: ~30,000 | Repositories flagged: 654 | Confirmed fully exploitable: 300+ | Confirmed affected: Microsoft Azure Sentinel · Google AI Agent Development Kit · Apache Doris · Cloudflare Workers SDK · Python Software Foundation Black | CVE assigned: No — this is a class of misconfiguration, not a single bug in any one product | Exploitation in the wild: No confirmed cases — Novee conducted responsible disclosure | Fix status: Microsoft and Google confirmed impact; Cloudflare, Apache, and Python PSF applied patches and hardening | Potential scale: Millions of repositories

A free GitHub account. That’s all it takes to push malicious code into Microsoft, Google, and Cloudflare’s build pipelines.

On June 24, 2026, penetration testing firm Novee Security published research that reframes how the security industry should think about CI/CD configurations, GitHub Actions workflows, and the open-source software supply chain. The vulnerability class they named Cordyceps — after the parasitic fungus that hijacks its host’s nervous system and controls its behavior from within — is not a bug in any single piece of software. It is a systemic, structural flaw in how GitHub Actions workflows are composed: a pattern of insecure workflow interaction that allows an unauthenticated attacker with a free GitHub account to traverse a chain of workflows, cross privilege boundaries, and emerge with production credentials, write access to protected branches, or the ability to publish poisoned packages to npm, PyPI, crates.io, Docker, and Helm.

Novee scanned approximately 30,000 high-impact open-source repositories across the npm, PyPI, crates, and Go ecosystems. A single scan flagged 654 repositories. More than 300 were confirmed fully exploitable — meaning Novee validated complete attacker-controlled code execution, credential theft, or supply chain compromise chains, not merely theoretical risk. The confirmed affected organizations include Microsoft, Google, Apache, Cloudflare, and the Python Software Foundation. All have since applied fixes or hardening. No exploitation in the wild has been confirmed. The potential scale, per Novee’s own assessment: millions of repositories may carry the same vulnerable pattern.

As Elad Meged, Novee’s founding engineer, describes it: “The flaw is exploitable by any unauthenticated user. No org membership or special privileges; a free account is enough to forge approvals, push code, or steal credentials. This is a CI/CD vulnerability pattern that the biggest, best-resourced engineering teams in the world keep making.”

What Cordyceps actually is — and why scanners can’t see it

Cordyceps is not a single vulnerability with a CVE number and a specific patch. It is a class of insecure workflow composition — a pattern of how multiple GitHub Actions workflows interact with each other in ways that create privilege escalation and credential theft paths that no individual workflow, viewed in isolation, makes obvious.

The structural problem is how GitHub Actions handles trust across workflow boundaries. In GitHub’s model, workflows triggered by external pull requests run with restricted permissions — they cannot access secrets or push to protected branches. This is the security boundary. But many repositories have a second class of workflows — triggered by events like pull_request_target or workflow_run — that run in the context of the base repository and do have access to secrets and protected branch write permissions. The Cordyceps vulnerability class occurs when an output, artifact, or variable from an untrusted low-privilege workflow is passed — without sanitization or trust validation — into a high-privilege workflow that then uses that data in a shell command or authentication step.

The exploit chain, generalized across the 300+ confirmed cases, follows four steps:

1. Attacker triggers entry. An unauthenticated attacker with a free GitHub account submits a malicious pull request, comments on a PR, or crafts a branch name. The specific trigger varies by repository but requires no organizational access.
2. Low-privilege workflow executes attacker-controlled input. A CI workflow triggered by the attacker’s action runs in restricted context but processes the attacker’s input — a branch name, a comment body, a PR title — as part of a shell command or environment variable without sanitization.
3. Untrusted data crosses the privilege boundary. The output, artifact, or environment variable from the low-privilege workflow flows — through a legitimate workflow composition mechanism like workflow_run, actions/download-artifact, or environment variable passing — into a high-privilege workflow that has access to repository secrets, cloud credentials, or protected branch write permissions.
4. High-privilege workflow executes attacker-controlled code or exposes credentials. The high-privilege workflow uses the tainted data in a shell command or authentication step, producing attacker-controlled code execution, credential exfiltration, or supply chain compromise.

As Novee describes it: “This supply chain vulnerability lies in the foundational open-source plumbing the entire industry runs on, and the kind of issue that hides from scanners because, technically, every individual piece is working as designed. The workflow does what it was told. The vulnerability exists only in the composition — untrusted data crossing a trust boundary that no one audited.”

This is precisely why standard security scanners miss it. A static scanner reads individual YAML files, validates syntax, checks for known-bad patterns like pull_request_target combined with actions/checkout, and flags what it sees. It does not reason about how a low-privilege workflow’s outputs flow into a high-privilege workflow downstream. It sees valid YAML at every step. An attacker — or Novee’s AI-assisted scanner — sees a four-step path to permanent cloud credentials.

The five confirmed cases — what Novee actually achieved at each organization

1. Microsoft Azure Sentinel

What Novee found: A comment on a pull request could execute arbitrary attacker code on Microsoft’s CI runners and steal a non-expiring GitHub App key. The key would grant persistent write access to security content deployed directly into customer Azure Sentinel workspaces via the Azure Marketplace.

Why this matters: Azure Sentinel is Microsoft’s enterprise SIEM platform — deployed across thousands of enterprise and government security operations centers. Persistent write access to security content deployed to customer Sentinel workspaces means an attacker could silently modify detection rules, disable alerts, or inject malicious hunting queries across every Sentinel customer environment that pulls from the compromised source. This is the security tool supply chain attack DataWater documented with CVE-2026-20253 in Splunk Enterprise — except here the compromise path runs through the build pipeline rather than the runtime service.

2. Google AI Agent Development Kit (adk-samples)

What Novee found: A single malicious pull request could execute attacker code on Google’s CI runners with full owner-level permissions over the associated Google Cloud project — the highest possible privilege level.

Why this matters: The adk-samples repository is the official Google sample repository for building AI agents using Google’s Agent Development Kit. Organizations building AI agent applications on Google Cloud use this as reference infrastructure. Owner-level access to the Google Cloud project means the attacker would have the ability to modify the sample code itself, inject malicious dependencies into the official samples, or compromise the build and distribution pipeline for a widely-referenced developer resource.

3. Apache Doris

What Novee found: Two independent zero-click attack paths — one triggered by a single comment on any pull request, one triggered by a forked PR — could exfiltrate hard-coded CI credentials or steal a token with full write permissions across repository contents and Actions.

Why this matters: Apache Doris is a widely deployed real-time analytics database used across enterprise data infrastructure. Full write access to repository contents and Actions means an attacker could modify the source code and the CI/CD pipeline simultaneously — producing a supply chain compromise that would flow into every organization building and deploying Doris from source. The Apache Security Team confirmed the finding and applied fixes.

4. Cloudflare Workers SDK (Wrangler CLI)

What Novee found: A pull request with a specially crafted branch name could trigger arbitrary command execution on Cloudflare’s CI runners. Novee confirmed code execution on their CI; no production secrets were reachable from this specific entry point, but the pattern persisted until Cloudflare applied broad hardening across their workflows.

Why this matters: Wrangler is the official CLI tool for building on Cloudflare Workers — the platform powering millions of edge applications globally. Arbitrary code execution on Cloudflare’s CI runners gives an attacker a foothold from which to pivot toward build artifacts, developer credentials, and the distribution pipeline for a tool that every Cloudflare Workers developer uses.

5. Python Software Foundation — Black (130 Million Monthly Installs)

What Novee found: A malicious pull request could run on Black’s build systems, steal the project’s automation bot token, and forge PR approvals as the project bot — creating a path to tainted releases published to PyPI for 130 million monthly installs.

Why this matters: Black is the de-facto standard Python code formatter — used by virtually every Python developer and integrated into CI pipelines, pre-commit hooks, and IDE extensions globally. A tainted Black release published to PyPI would reach 130 million monthly install events, potentially embedding malicious code into every Python project that uses Black as a dependency. This is the downstream blast radius that makes the Black finding the most consequential single case in Novee’s research from a pure supply-chain-infection-scale perspective.

Why AI coding agents are making Cordyceps worse — at exponential scale

The most structurally alarming finding in Novee’s research is not any specific exploit against a named organization. It is the observation that AI coding agents are actively propagating the Cordyceps vulnerability pattern across millions of repositories at scale.

When a developer asks an AI coding agent — GitHub Copilot, Claude Code, Cursor, or any equivalent — to generate a CI/CD workflow for their project, the agent produces YAML based on patterns it has learned from the training corpus. If the insecure workflow composition patterns that create Cordyceps are common in that training corpus — which Novee’s finding that 654 of 30,000 high-impact repositories carry them suggests they are — then AI agents will reproduce those patterns in every workflow they generate. The agent is not making a security mistake; it is doing exactly what it was trained to do, which is generate functional CI/CD configurations. The security flaw exists in the composition, not in any individual workflow, and the agent has no mechanism for reasoning about cross-workflow trust boundaries that it was not specifically trained to evaluate.

As Meged describes it: “AI coding agents are scaling the problem. They generate CI/CD configuration fast and reproduce the same insecure patterns over and over, so the same mistakes can compound across millions of repositories.” And: “The nature of agentic coding means these CI/CD vulnerabilities are reproduced persistently, at scale, ‘infecting’ repositories at an exponential rate.” SecurityWeek’s coverage frames the downstream consequence directly: “When that same software is then installed by thousands of organizations, one compromised workflow in one repository can ripple outward into banks, cloud accounts, AI labs, and end-user devices.”

This creates a feedback loop with no natural stopping point. Every new repository created with AI-assisted CI/CD configuration has a probability of carrying the Cordyceps pattern. Every organization that installs or depends on a compromised package is downstream of that repository’s build pipeline. The supply chain infection model is, as Novee explicitly names it, agentic — self-replicating through the AI tools the industry has adopted to accelerate development velocity.

How to audit your CI/CD workflows for Cordyceps — right now

Step 1 — Find all pull_request_target and workflow_run triggered workflows

# Find all workflows triggered by pull_request_target (runs in base repo context — has secrets)
grep -r "pull_request_target" .github/workflows/

# Find all workflows triggered by workflow_run (may inherit high privilege)
grep -r "workflow_run" .github/workflows/

# Find all workflows that download artifacts from other workflows
grep -r "actions/download-artifact" .github/workflows/

# These are your highest-risk workflows — audit each one manually

Step 2 — Check for untrusted input interpolation in shell commands

# Dangerous patterns — PR metadata flowing directly into shell commands:
# ${{ github.event.pull_request.title }}
# ${{ github.event.pull_request.body }}
# ${{ github.event.pull_request.head.ref }}  (branch name — like Cloudflare's case)
# ${{ github.head_ref }}
# ${{ github.event.comment.body }}

# Search for these patterns in shell steps:
grep -r "github.event.pull_request" .github/workflows/
grep -r "github.head_ref" .github/workflows/
grep -r "github.event.comment" .github/workflows/

# Any of these appearing inside a run: shell step or being passed to
# a high-privilege workflow via environment variables or artifacts = audit immediately

Step 3 — Validate trust boundaries between workflow privilege tiers

For each workflow_run or pull_request_target workflow that downloads artifacts or reads outputs from a lower-privilege workflow: confirm that the data flowing across that boundary is validated and sanitized before it reaches any shell command, authentication step, or credential-adjacent operation. If you cannot confirm this — treat the boundary as potentially exploitable and remediate.

Step 4 — Pin all GitHub Actions to commit SHAs

# BAD — mutable tag, can be changed by the action owner:
- uses: actions/checkout@v4

# GOOD — pinned to specific commit SHA:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2

# Use a tool like pin-github-actions to automate SHA pinning:
# https://github.com/mheap/pin-github-action

Step 5 — Audit and rotate all CI/CD secrets

• Audit every secret stored in GitHub Actions Settings → Secrets and Variables → Actions
• Identify and immediately rotate any non-expiring tokens or GitHub App keys
• Audit cloud provider credentials (AWS, GCP, Azure) stored as Actions secrets — rotate any that have been present in workflows carrying the Cordyceps pattern
• Replace long-lived credentials with OIDC-based short-lived token issuance where possible — GitHub Actions supports OIDC with AWS, GCP, and Azure

The structural lesson: workflow code is code

Cordyceps exists primarily because the security industry has not yet internalized a simple principle that Novee’s research makes unavoidable: GitHub Actions .yml files are code, not configuration. The distinction matters because organizations apply security review processes, threat modeling, code scanning, and change control to application code. They do not reliably apply those same processes to CI/CD workflow files, which are typically treated as operational scaffolding maintained by DevOps engineers rather than security-reviewed assets.

Meged’s summary to Dark Reading frames the required mindset shift precisely: “CISOs should think about CI/CD workflows as code assets subject to the same requirements as applications, because, simply put, ‘workflow code is code.'” The same review standards that would catch command injection in application source code would catch the Cordyceps pattern in a workflow YAML file — if those review standards were applied to workflow YAML files in the first place.

This is the third major supply chain security story DataWater has covered in 2026, following TeamPCP’s Megalodon campaign against Nx Console and GitHub Actions and the Mastra npm supply chain attack attributed to North Korea’s Sapphire Sleet. All three exploited the same structural blind spot: the CI/CD pipeline as an attack surface that most organizations secure to a significantly lower standard than their application code, despite the fact that a compromised build pipeline produces compromised software that flows downstream to every user of every affected package.

Sources and further reading

• Novee Security — Cordyceps: The Silent Parasite Consuming Your Supply Chain (Primary Research)
• The Hacker News — Cordyceps CI/CD Flaws Expose 300+ GitHub Repositories to Supply-Chain Attacks
• SecurityWeek — Exploitable CI/CD Vulnerabilities Expose Millions of Repositories to Hijacking
• Dark Reading — Cordyceps: Malicious Pull Requests Threaten CI/CD Workflows
• Hackread — Cordyceps CI/CD Flaw Exposes Microsoft, Google, Apache Repos to Pipeline Hijacking
• CybersecurityNews — Cordyceps Supply Chain Flaw Impacting Code Repositories at Thousands of Organizations
• GBHackers — Cordyceps Supply Chain Vulnerability Impacting Code Repositories

DataWater publishes daily cybersecurity intelligence for enterprise and government security leaders. Article #33 — June 25, 2026. Previous: Squidbleed CVE-2026-47729 (June 23) · FortiBleed CISA Advisory Update (June 20) · FortiBleed Original Analysis (June 18). Browse the full threat brief archive →