Novee Security reported more than 300 fully exploitable attack chains after scanning roughly 30,000 high-impact open-source repositories. The affected projects included repositories at Microsoft, Google, Apache, Cloudflare, and the Python Software Foundation.

The researchers called the vulnerability class Cordyceps, after the fungus that takes over its host. According to Novee, a free, anonymous GitHub account was enough to exploit the affected workflows, with no organization membership required. Depending on the attack chain, an attacker could steal non-expiring credentials, push malicious code, or obtain owner-level permissions on cloud infrastructure.

The common problem was executable logic hidden behind the familiar appearance of workflow YAML. GitHub Actions workflows can process public input while holding credentials that allow them to change repositories, publish packages, or deploy infrastructure. A pull request title or comment becomes dangerous when a workflow treats it as code.

How the attacks cross into trusted code

Cordyceps isn't a single CVE. It describes recurring vulnerability patterns in GitHub Actions workflows. Their impact depends on the permissions and credentials available to the affected jobs.

One entry point is direct interpolation: a workflow inserts an externally controlled value into a shell command or JavaScript before executing it. A branch name, pull request title, or comment can then change what the step runs.

Novee identified four categories:

  • Command injection. A workflow inserts a branch name or pull request title directly into a shell command. One example is run: echo "Branch: ${{ github.event.pull_request.head.ref }}", where head.ref is controlled by the attacker.
  • Code injection. Untrusted input reaches actions/github-script and becomes part of the JavaScript that the action evaluates.
  • Broken authorization. A permission check exists, but a logic error allows carefully shaped input to bypass it.
  • Cross-workflow escalation. A low-privilege workflow produces data, such as an artifact or an environment value passed onward, that a more privileged workflow later consumes unsafely.

Cross-workflow escalation is especially difficult to spot in a file-by-file review. The first workflow may safely handle untrusted data under limited permissions. The second may appear to read an ordinary build result. The vulnerability becomes clear only when the review follows that data from its external source into the privileged job.

The Hacker News reported that existing tools could not reason about these cross-workflow findings. The relevant limitation is the scope of analysis: a static application security testing tool that examines files in isolation can miss a trust boundary crossed between separate workflows.

What the researchers found

In Microsoft's Azure Sentinel repository, Novee found that a pull request comment could trigger code execution on Microsoft's CI runners and expose a non-expiring GitHub App key. The repository distributes security detection rules to enterprise customers. Persistent write access would create a path to tamper with rules that downstream organizations rely on, extending the risk beyond the repository itself.

In Google's AI Agent Development Kit, the researchers reported that a single pull request could execute attacker-controlled code in Google's CI environment and obtain roles/owner on the associated Google Cloud project. The reported impact was full administrative control over that project's resources.

At Apache Doris, Novee found two independent paths: credential exfiltration through a comment and token theft through a pull request from a fork. Either path reportedly allowed an attacker to modify source code that users could later compile and ship. Apache Doris was described as having more than 10,000 enterprise users.

Cloudflare's Workers SDK had a command-execution vulnerability triggered by crafted branch names. In the Python Software Foundation's Black formatter, the researchers found a route to steal bot automation tokens and approve pull requests without human review. The reported distribution footprint for Black included Docker images downloaded 130 million times per month.

As of June 25, 2026, Microsoft and Google had confirmed impact. According to Dark Reading, Apache, Cloudflare, and the Python Software Foundation had applied patches.

The scan covered roughly 30,000 prominent repositories, not the full population of GitHub Actions users. Similar patterns may exist across millions of private organizational repositories, but the reported findings don't establish how many of those repositories are exploitable.

AI-generated workflows can repeat the same mistakes

Novee's root-cause analysis also identified AI coding agents as a source of repeated vulnerable patterns. Tools such as Cursor, Claude Code, and GitHub Copilot can generate a workflow that is valid YAML and performs the requested task while still mishandling untrusted input.

The concern is that insecure examples become templates for new code. Directly inserting ${{ github.event.pull_request.title }} into a shell command can look reasonable during an ordinary functionality review. If a linter accepts the syntax and the workflow passes its tests, neither result establishes that the interpolation is safe.

The argument that training data contains millions of vulnerable workflows, and that most linters failed to flag these patterns, helps explain the proposed mechanism. It doesn't establish the training contents or behavior of each named coding tool. The practical concern is narrower: generated workflows can reproduce existing security mistakes, and faster generation can add to the amount of privileged code requiring review.

CI/CD makes those mistakes consequential because the same automation often pulls source from GitHub, pushes images to registries, and deploys to cloud accounts. External input can enter early in that process and reach a credential-bearing step later. Reviewing only the final deployment command leaves much of that path unchecked.

Where workflow reviews should start

The first review targets should be workflows that deploy to production, publish container images, or use cloud credentials. For each one, trace externally controlled input from its entry point to every step that consumes it. That includes pull request titles, branch names, commit messages, comments, and attacker-controlled fields within github.event.

  1. Keep external values out of executable source. Avoid interpolating ${{ github.event.* }} directly into run: blocks. Pass external values through environment variables and reference them with shell variable syntax. This keeps the initial substitution out of the shell script's source, though later commands still need to handle the values safely.
  2. Audit every use of pull_request_target. This trigger can run with write permissions for pull requests from forks. Review its effective permissions and every point where it touches external input or untrusted code.
  3. Map cross-workflow data flows. Record artifacts, cache entries, and environment values passed between workflows. Check whether a privileged consumer trusts data produced by a less privileged job.
  4. Restrict permissions at the job level. Use permissions: blocks to grant only the scopes each job needs. Check effective defaults rather than assuming that an unspecified permission is restricted.
  5. Review workflow changes as code changes. Authentication logic and infrastructure changes receive security review because they control access and execution. Workflow YAML needs comparable scrutiny when it performs those same functions.

Novee's technical write-up provides the detailed attack paths. SecurityWeek's coverage discusses the broader concern that similar patterns may affect millions of repositories.

The findings at organizations with established security programs show how easily workflow behavior can escape ordinary review. A workflow may read secrets from a vault, publish a container image, or deploy to a production Kubernetes cluster. Its security review has to cover both those permissions and the route by which external data reaches them, including handoffs between files that look harmless on their own.