Most supply-chain attacks make people think about poisoned packages, compromised dependencies, or malicious updates. Megalodon was different. It did not need to hide inside an npm package or wait for a developer to install the wrong library. It went after the place many teams trust the most and often monitor the least: the CI/CD pipeline.
In May 2026, researchers reported a large automated campaign known as Megalodon, also tracked as MEGALODON_CI, that pushed malicious GitHub Actions workflow changes into thousands of public repositories. The attack reportedly involved 5,718 malicious commits across 5,561 repositories in roughly six hours. That speed is the story. This was not a slow manual compromise of one project at a time. It looked like automation built to abuse GitHub at scale.
The important lesson is simple: your workflow files are production infrastructure. If an attacker can change .github/workflows/, they may not need to change your app at all.
What Megalodon Actually Did
Megalodon poisoned GitHub Actions workflows.
Instead of modifying application source code, the attackers injected malicious workflow steps into CI files. These changes were made to look like normal automation maintenance. Some used names that sounded harmless, like routine build improvements or diagnostic tasks.
Inside the workflow, the attackers used encoded shell commands that executed inside the GitHub Actions runner. From there, the payload searched for secrets and credentials available to the CI environment.
That is what made the attack dangerous. CI runners often have access to the things attackers actually want:
- GitHub tokens
- Repository secrets
- Cloud credentials (AWS, Azure, GCP)
- SSH keys and deploy keys
- Package registry tokens
- Docker and Kubernetes configs
- Environment files and
.envvariables - Service account credentials
- Terraform credentials
- OIDC tokens used to access cloud providers
In other words, the attacker did not just want the code. They wanted the keys that let code become infrastructure.
Why This Was a Zero-CVE Problem
A lot of security programs are built around CVEs. Patch the vulnerable server. Update the bad library. Scan the dependency tree. That work matters, but it would not reliably catch Megalodon.
There was no single vulnerable library to patch. No classic remote code execution bug. No neat advisory that says "upgrade from version X to version Y."
The weak point was trust.
If a malicious workflow lands in a repository and gets executed by a privileged runner, the pipeline itself becomes the exploit. That is why this type of campaign is sometimes described as zero-CVE. The attacker abuses legitimate automation, legitimate GitHub Actions behavior, and legitimate access paths.
That should make defenders uncomfortable. A workflow file can be only a few lines long and still have access to the crown jewels.
How the Attack Blended In
Megalodon did not announce itself with obvious malware filenames. It blended into the normal noise of software projects.
The commits were designed to look like ordinary CI maintenance. That matters because CI files are often treated as plumbing. Developers review application code carefully, then skim workflow changes because they appear operational and unglamorous.
That habit is exactly what an attacker wants.
A small workflow change can do more damage than a large application change. Application code usually runs after deployment. Workflow code runs during build, test, package, release, and deployment. It may touch every environment on the way out.
The OIDC Problem
One of the more serious dimensions of this campaign is the risk around OIDC tokens.
Many modern CI/CD setups avoid storing long-lived cloud keys in GitHub. That is good practice. Instead, they allow GitHub Actions to request short-lived tokens from a cloud provider using OpenID Connect. That is usually safer than hardcoded credentials.
But it is not magic.
If an attacker controls a workflow with permission to request identity tokens, they may be able to mint a short-lived cloud token from inside the runner. If the cloud trust policy is too broad, that token can become access to AWS, Azure, or GCP.
So even teams that proudly removed static cloud secrets from GitHub still need to ask: can an attacker modify a workflow and request cloud access from it?
If the answer is yes, the organization still has a serious pipeline security problem.
What Was at Risk
Public reporting described the payload as a broad credential harvester. It searched the runner environment and repository workspace for anything useful.
That kind of theft can create a second wave of compromise:
- One stolen package token can lead to a poisoned release
- One stolen cloud token can lead to infrastructure access
- One stolen deploy key can lead to more repositories
- One stolen GitHub token can turn one compromise into many
That is the real danger of CI/CD attacks. The pipeline sits between code, identity, infrastructure, and release systems. It is a bridge. Attackers love bridges.
How Teams Should Respond
If a malicious workflow ran in your repository, assume exposed secrets are compromised. Do not only delete the workflow and move on.
Immediate containment:
- Disable or remove the suspicious workflow
- Stop affected self-hosted runners, if any were used
- Preserve workflow logs before they expire
- Identify which secrets and permissions were available to the workflow
- Rotate everything the job could access
That last point matters. Rotate based on access, not based on proof of theft. If the workflow could read a secret, treat it as stolen.
What to rotate:
GitHub Actions secrets, GitHub personal access tokens, deploy keys, SSH keys, package registry tokens, cloud credentials (AWS, Azure, GCP), database credentials, API keys, and service account credentials that may have been accessible to the affected workflow.
Then look downstream. Review cloud activity logs, package release history, GitHub access changes, new or modified deploy keys, unusual workflow runs, and any unexpected changes to release or deployment systems.
How To Make This Harder Next Time
The fix is not one tool. It is changing how teams treat CI/CD.
Protect workflow files. Changes to .github/workflows/** should require code-owner review. Not casual review — real review from someone who understands what the workflow can access and what it touches.
Use least privilege for GitHub Actions permissions. Do not give workflows broad write access by default. Start with read-only and grant extra permissions only to the jobs that truly need them.
Restrict OIDC trust policies. Limit cloud trust to specific repositories, branches, environments, and workflow contexts. Avoid broad rules that allow any workflow from a repository to assume powerful cloud roles.
Separate untrusted and trusted workflows. Pull request checks should not have the same permissions as deployment workflows. External contributions should never get access to production secrets.
Pin third-party GitHub Actions to commit SHAs where practical. Tags can move and can be silently updated. SHAs are immutable and cannot be rewritten without changing the reference.
Treat self-hosted runners as sensitive servers. If a malicious job ran on a long-lived self-hosted runner, the risk is larger than on a fresh ephemeral runner. Long-lived runners may have cached credentials, local files, shell history, and access to internal networks.
The Bigger Lesson
Megalodon is a reminder that software supply-chain security is no longer just about dependencies. The build system is part of the product. The pipeline is part of the attack surface. Workflow files are executable code.
For years, teams have asked: Can attackers change our source code?
Now they need to ask a sharper question:
Can attackers change the system that builds, signs, tests, packages, and deploys our source code?
If they can, they may not need to touch the app at all.
Sources: - StepSecurity — Megalodon: Mass GitHub Actions Secret Exfiltration Across 5,500+ Public Repositories - The Hacker News — Megalodon GitHub Attack Targets 5,561 Repos with Malicious CI/CD Workflows