The Megalodon GitHub Attack: 5,561 Repositories Backdoored in Six Hours — What Your Development Team Must Do Now

On 18 May 2026, a campaign codenamed Megalodon pushed 5,718 malicious commits into 5,561 GitHub repositories in a single six-hour window. The payloads — disguised as routine CI configuration updates — silently exfiltrated cloud credentials, SSH keys, OIDC tokens, and source code secrets from every CI/CD runner they touched. It is, by volume, one of the most aggressive GitHub Actions poisoning campaigns ever recorded.

If your team ships code through GitHub Actions — and statistically, you almost certainly do — this is not optional reading.

TL;DR

• The Megalodon campaign backdoored 5,561 GitHub repositories between 11:36 and 17:48 UTC on 18 May 2026 using forged bot identities and innocuous-looking commit messages.
• Two payload variants were deployed: a mass-trigger workflow (SysDiag) firing on every push and PR, and a targeted dormant backdoor (Optimize-Build) activated on demand via the GitHub API.
• Exfiltrated data included AWS credentials, GCP tokens, SSH keys, Docker and Kubernetes configs, Vault tokens, GitHub OIDC tokens, and secrets matching 30+ regex patterns.
• The attack exploited weak branch protection, overly permissive workflow triggers, and the implicit trust most teams place in CI configuration files.
• Immediate actions: audit your .github/workflows/ directory, rotate all CI/CD secrets, enforce branch protection with required reviews, and adopt GitHub’s Trusted Publishing mechanisms.

What Happened: Anatomy of the Attack

The Megalodon campaign was automated, fast, and disturbingly simple. Between 11:36 a.m. and 5:48 p.m. UTC, throwaway GitHub accounts pushed commits to thousands of repositories using forged author identities — names like build-bot, auto-ci, ci-bot, and pipeline-bot. Each commit carried one of seven carefully crafted messages designed to pass casual review:

• ci: add build optimization step
• chore: optimize pipeline runtime
• ci: update workflow configuration

These are exactly the kind of commits most developers glance at and skip. That was the point.

The injected workflows contained base64-encoded bash payloads that, once triggered by GitHub Actions runners, systematically harvested credentials from the CI environment and exfiltrated them to a command-and-control server at 216.126.225[.]129:8443.

Two Payload Variants, Two Strategies

SysDiag: The Dragnet

The mass variant added a new workflow file triggered on every push and pull_request event. The goal was volume — maximise the number of automated executions across as many repositories and contributors as possible. Every time a developer pushed code or opened a PR, the payload ran silently alongside legitimate CI jobs.

Optimize-Build: The Sleeper

The targeted variant was more surgical. It replaced existing workflow files with ones triggered only via workflow_dispatch — meaning the attacker could fire the payload on demand through the GitHub API whenever they chose. This created dormant backdoors in repositories, invisible until activated. The @tiledesk/tiledesk-server npm package was one confirmed target of this approach.

What Was Stolen

The payload was comprehensive. It harvested:

• Cloud provider credentials: AWS access keys (including IMDSv2 instance role tokens), Google Cloud access tokens, and Azure IMDS credentials
• Infrastructure secrets: SSH private keys, Docker configuration files, Kubernetes configs, and HashiCorp Vault tokens
• CI/CD tokens: GitHub Actions OIDC tokens, CI runner tokens, and pipeline secrets
• Application secrets: API keys, JWTs, PEM certificates, and anything matching over 30 regex patterns designed to catch common secret formats

In short, if it was accessible from the runner environment, it was exfiltrated. For teams with overly permissive CI configurations — and that is a great many teams — this means the blast radius extends well beyond the compromised repository itself.

Why This Worked

Megalodon did not exploit a zero-day. It did not require sophisticated tooling. It exploited something far more fundamental: the implicit trust most development teams place in their CI/CD configuration files.

Several structural weaknesses made this possible:

1. Insufficient branch protection. Repositories without required review approvals allowed direct pushes to default branches — including from newly created accounts.
2. Overly permissive workflow triggers. Workflows triggered on push and pull_request from any contributor run automatically unless explicitly restricted.
3. Workflow files are not treated as security-critical. Most teams review application code carefully but wave through CI configuration changes. Megalodon’s commit messages were engineered to exploit exactly this blind spot.
4. Flat secret scoping. CI runners with access to production credentials, cloud tokens, and infrastructure secrets provide an enormous attack surface when compromised.

What Your Team Must Do Now

1. Audit Your Workflow Directory Immediately

Check every file in .github/workflows/ across all your repositories. Look for:

• Unfamiliar workflow files you did not create
• Base64-encoded strings in run steps
• Outbound network calls to unfamiliar IPs or domains
• Commits from authors like build-bot, auto-ci, ci-bot, or pipeline-bot

2. Rotate All CI/CD Secrets

If any of your repositories were affected — or if you cannot confirm they were not — rotate every secret accessible from your CI runners. This includes cloud provider credentials, API keys, SSH keys, and any tokens stored as GitHub Actions secrets.

3. Enforce Branch Protection

At minimum, require pull request reviews before merging to your default branch. Consider requiring CODEOWNERS approval specifically for changes to .github/workflows/ files.

4. Scope Your Secrets Properly

CI runners should not have access to every secret your organisation owns. Use environment-scoped secrets, restrict OIDC token audiences, and follow the principle of least privilege for every pipeline stage.

5. Adopt Trusted Publishing

npm has urged migration to Trusted Publishing mechanisms that eliminate long-lived access tokens. If you are still using granular access tokens with write permissions, the Megalodon campaign is your signal to move.

6. Monitor Workflow Changes

Treat .github/workflows/ as a security-critical directory. Set up alerts for any modifications, and consider requiring a dedicated security review for workflow file changes.

The Bigger Picture: Supply Chain Attacks Are Industrialising

Megalodon is not an isolated incident. It follows the TanStack supply chain attack, the GitHub internal breach by TeamPCP, and a steady drumbeat of CI/CD-targeted campaigns throughout 2026. The pattern is clear: attackers have recognised that CI/CD pipelines are the softest target in most organisations’ security posture.

The traditional security perimeter — firewalls, endpoint protection, network segmentation — does not protect your build pipeline. Your pipeline trusts code, and if that code is poisoned, everything downstream is compromised.

At REPTILEHAUS, we help development teams build CI/CD pipelines that are secure by default — with proper secret scoping, workflow review gates, OIDC-based authentication, and automated anomaly detection. If you are not confident your pipeline would survive a Megalodon-style attack, get in touch. This is exactly the kind of infrastructure work that pays for itself the first time it prevents a breach.

Final Thought

5,561 repositories in six hours. The attackers did not need to be clever — they just needed your team to treat workflow files as routine maintenance. The fix is not a tool or a product. It is a cultural shift: your CI/CD configuration is code, and it deserves the same scrutiny as any code that touches production.

📷 Photo by Markus Spiske on Unsplash