Researchers Disclose "Cordyceps" CI/CD Flaws Affecting 300+ GitHub Repositories

Supply-chain audit work for organizations using GitHub-hosted CI/CD: a research firm found a recurring pull-request handling and workflow-permission pattern that left 300-plus repositories open to attacker-controlled code execution.

TEL AVIV — Researchers at Novee Security on June 24, 2026 disclosed a systemic class of Continuous Integration / Continuous Deployment (CI/CD) workflow weaknesses they have codenamed "Cordyceps," which the firm says left more than 300 GitHub repositories — including build tooling behind Microsoft, Google, Apache, Cloudflare, and the Python Software Foundation — open to supply-chain compromise. The flaw is not a vulnerability in GitHub itself but a recurring misconfiguration in how repositories handle pull requests submitted by untrusted outside contributors, and how much privilege the automated workflows triggered by those pull requests are granted.

The disclosure reads as a configuration-hygiene problem at scale rather than a single breach, and that framing matters for defenders. Novee said it scanned roughly 30,000 high-impact repositories, flagged 654 in a single automated pass, and confirmed more than 300 as fully exploitable. The firm reported no evidence that the pattern has been broadly abused in the wild, and said affected organizations confirmed fixes after responsible disclosure. For everyone else running GitHub-hosted automation, the takeaway is an audit task that sits alongside prior pull-request supply-chain incidents rather than a one-off.

What the Researchers Disclosed

Novee Security described Cordyceps as a recurring, exploitable pattern across Continuous Integration / Continuous Deployment (CI/CD) pipelines — the automated systems developers use to build, test, and publish software — rather than a single defect in one product. According to the firm, the pattern most often appears in GitHub Actions workflows but is equally applicable to other automation systems that grant pull requests more permission than they should have. The named brand, Cordyceps, is a research codename chosen for a parasitic fungus; it is not a CVE identifier, and there is no single patch that closes it.

The researchers said they scanned roughly 30,000 high-impact repositories, flagged 654 in one automated pass, and confirmed more than 300 as fully exploitable. Among the named examples in the disclosure, Novee described a pull-request comment on Microsoft's Azure Sentinel project that it said could run outside code on Microsoft's CI and reach a non-expiring GitHub App key; a single pull request to Google's AI Agent Development Kit that could reach the highest Google Cloud role; and a path in the Python Software Foundation's Black project by which a pull request could reach an automation token used by the project bot. Novee said Microsoft, Google, Apache, Cloudflare, and the Python Software Foundation confirmed fixes after disclosure.

A notable secondary finding concerns how the pattern spreads. Novee said AI coding agents now generate large volumes of CI/CD configuration files, and that those tools reproduce the same insecure workflow patterns repeatedly — meaning the same class of misconfiguration can be planted across many new repositories without any single author intending it. The firm reported no evidence that Cordyceps has been broadly exploited in the wild, a point worth holding alongside the scale figures rather than reading the 300-plus as an active-campaign count.

Defender Posture for GitHub-Hosted CI/CD Workflows

For organizations that run software on GitHub-hosted CI/CD, the value of this disclosure is less the specific named repositories and more the pattern it generalizes. The underlying issue is trust: a workflow that runs in response to a pull request from an outside contributor is, by definition, executing logic that an untrusted party influenced. When that workflow also holds secrets, signing keys, or cloud credentials, the gap between "untrusted input" and "privileged execution" becomes the whole attack surface. The same dynamic underpinned earlier pull-request handling incidents, including the pull_request_target pwn-request cases that hit major vendors this year.

Novee's framing is that the danger is rarely a single misconfigured line. In the chains the firm described, an untrusted pull request triggers a low-privilege workflow, and the output of that step then flows into a separate, higher-privilege workflow that authenticates to a cloud environment or reaches a long-lived token. Each individual step can look reasonable in isolation; the exposure emerges from the combination. For defenders, that means a review focused only on which workflows obviously touch secrets will miss the cross-workflow paths where privilege is inherited indirectly.

It also means the relevant question for most teams is not "are we Cordyceps" but "do we have any workflow that an outside contributor can trigger, which then reaches privilege we would not hand that contributor directly." Because the flaw is exploitable, in Novee's account, by any unauthenticated user with a free account — no organization membership required — the precondition that often slows an attack, needing valid internal credentials first, is absent. That lowers the bar for opportunistic discovery once the pattern is widely understood, which is the situation defenders now face.

Audit of Pull-Request Handling and Workflow-Permission Configuration

The concrete defender work breaks into two reviews: how pull requests trigger automation, and how much privilege that automation is granted. On the first, the high-risk pattern is a workflow that runs in a context where it can both be influenced by an untrusted pull request and access the repository's secrets — historically associated with triggers that run in the base repository's context while incorporating the fork's contents. Teams should enumerate every workflow that an outside pull request can start, and treat any that then reads secrets, checks out and executes fork-supplied code, or writes back to the repository as requiring deliberate justification.

The second review is permission scope. GitHub Actions lets repositories set the default token permissions for workflows, and the safer posture is to grant the minimum scope a job actually needs rather than broad read-write defaults inherited across the repository. The Cordyceps chains turn on privilege that flows further than intended, so the audit goal is to confirm that a workflow reachable from an untrusted pull request cannot reach signing keys, publishing tokens, or cloud roles — directly or by passing its output to a later, more privileged job. Where a privileged action genuinely must follow an external contribution, gating it behind a required human approval breaks the automatic path from untrusted input to privileged execution.

There is no Cordyceps CVE to apply and no GitHub product patch to install, because the weakness lives in customer-side configuration. GitHub's existing security guidance on preventing pwn requests and on restricting workflow permissions already describes the safe patterns; the disclosure is best read as a prompt to verify that those patterns are actually in force across an organization's repositories rather than assumed. Novee's own finding that AI-generated configuration reintroduces the insecure pattern argues for a recurring check rather than a one-time sweep, since new repositories and machine-generated workflow files can quietly reintroduce the exposure after a clean audit.

Open Questions

Several points remain in view. Novee reported no evidence of broad in-the-wild exploitation, so the 300-plus figure describes confirmed exploitability, not confirmed abuse — an important distinction when weighing urgency. The disclosure originates with a single research firm; its core claims were corroborated by multiple independent outlets and, per Novee, by confirmed fixes at the named organizations, but the full per-repository methodology behind the 30,000-scanned and 300-plus-confirmed figures sits with the researchers. How quickly the pattern is scanned for at scale now that it is publicly named — as has happened with other reachable, low-precondition CI/CD workflow weaknesses — is the open variable.

What is established is enough to act on: a widely reproduced misconfiguration pattern in pull-request handling and workflow permissions, exploitable without authentication, confirmed across hundreds of high-impact repositories and named as present in the build tooling of some of the largest engineering organizations in the world. Because the fix is configuration rather than a vendor patch, the burden sits with each repository owner. The durable control is the same one that outlasts any single named pattern: treat workflows reachable from untrusted pull requests as untrusted code, scope their permissions to the minimum, and gate privileged actions behind human review.

Defenders weighing where this sits relative to prior developer-trust incidents can compare it with the broader run of recent GitHub and developer-supply-chain coverage; the throughline is that the CI/CD layer itself is now a primary target, not a back-office utility.

Concrete CI/CD-defender audit checklist: (1) Enumerate every workflow that a pull request from an outside contributor can trigger, and flag any that read secrets, check out and run fork-supplied code, or write back to the repository. (2) Review trigger types — treat workflows that run in the base repository's privileged context while incorporating untrusted fork contents as high-risk and justify each one. (3) Set default workflow token permissions to read-only and grant write or elevated scopes per-job only where required. (4) Trace cross-workflow data flow: confirm no low-privilege, pull-request-triggered job passes output into a later job that holds signing keys, publishing tokens, or cloud roles. (5) Remove or shorten long-lived and non-expiring tokens and GitHub App keys reachable from CI; prefer short-lived, scoped credentials. (6) Require human approval before any privileged action that follows an external contribution, breaking the automatic path from untrusted input to privileged execution. (7) Re-run the audit on a schedule and on new repositories, since AI-generated configuration files can reintroduce the insecure pattern after a clean pass.

Sources