Megalodon: How 5,561 GitHub Repositories Got Backdoored in Six Hours

What Happened

On May 18, 2026, between 11:36 and 17:48 UTC, a supply chain campaign codenamed Megalodon pushed 5,718 malicious commits to 5,561 GitHub repositories in a single six-hour window — making it one of the largest automated GitHub Actions poisoning campaigns ever recorded (CyberSecurityNews). The attacker used throwaway accounts with randomized eight-character usernames and forged author identities like build-bot, auto-ci, ci-bot, and pipeline-bot, paired with emails [email protected] and [email protected]. Commit messages — "ci: add build optimization step" and "chore: optimize pipeline runtime" — were deliberately crafted to look like routine CI maintenance.

The attack's most consequential downstream impact hit Tiledesk, an open-source live-chat platform. The attacker compromised the GitHub repository and replaced the legitimate Docker build workflow with a dormant backdoor. The maintainer, unaware of the compromise, subsequently published @tiledesk/tiledesk-server versions 2.18.6 through 2.18.12 to npm — propagating the backdoor directly into the package registry (StepSecurity).

Technical Analysis: Poisoned Pipeline Execution at Scale

Megalodon is a textbook direct Poisoned Pipeline Execution (d-PPE) attack — an adversary with write access injects malicious code directly into workflow definition files, causing the CI system to execute attacker-controlled commands on the next pipeline run. Unlike indirect PPE (which requires tricking a maintainer into merging a malicious PR), d-PPE exploits direct push access to the default branch, bypassing pull request review entirely. This maps to MITRE ATT&CK T1195.002 (Supply Chain Compromise: Compromise Software Supply Chain).

The campaign deployed two distinct workflow variants sharing the same C2 server at 216.126.225.129:8443:

• SysDiag (Mass Variant): Added a new .github/workflows/ci.yml file triggered on every push and pull_request_target event, ensuring automated execution on any commit across all branches.
• Optimize-Build (Targeted Variant): Replaced existing workflows with a workflow_dispatch trigger — creating a dormant backdoor the attacker can silently activate on demand via the GitHub API, producing zero visible CI runs and no failed builds.

Both variants requested elevated permissions: id-token: write and actions: read, enabling OIDC token theft for cloud identity impersonation. The base64-encoded bash payload — a 111-line script — conducted aggressive, multi-phase credential harvesting once triggered: all CI environment variables, /proc/*/environ, PID 1 environment data, AWS credentials across all profiles, GCP access tokens via gcloud auth print-access-token, live credentials from AWS IMDSv2, GCP metadata, and Azure IMDS endpoints, SSH private keys, Docker auth configs, .npmrc, .netrc, Kubernetes configs, Vault tokens, and Terraform credentials. Source code was grep-scanned against 30+ regex patterns targeting API keys, JWTs, database connection strings, PEM keys, and cloud tokens (Hoplon InfoSec).

Who's Affected

The 5,561 compromised repositories span open-source projects used by millions of developers worldwide. The Tiledesk propagation means that any developer who installed @tiledesk/tiledesk-server versions 2.18.6 through 2.18.12 from npm may have pulled in the poisoned pipeline. Every CI runner triggered during the campaign window could have exfiltrated:

• AWS access keys, secret keys, and session tokens
• GCP service account and OAuth tokens
• Azure Managed Identity credentials
• GitHub Actions OIDC tokens (usable for direct cloud impersonation)
• SSH private keys and Kubernetes cluster credentials

The attacker specifically targeted repositories with weak branch protection — those without mandatory pull request reviews, where any account with write access (or any accepted PR from a public fork) could land workflow changes directly to the default branch (StepSecurity).

How to Protect Yourself

1. Audit your GitHub Actions workflows immediately. Check .github/workflows/ for unexpected files — especially ci.yml (SysDiag) or any workflow with workflow_dispatch trigger and id-token: write permissions (Optimize-Build). Look for base64-encoded bash steps or calls to unknown IPs.
2. Enforce mandatory PR reviews on all branches. Branch protection with required reviews is the single most effective control against d-PPE. It converts a direct-push opportunity into the harder i-PPE problem where an attacker must trick a maintainer into merging a malicious PR.
3. Rotate all CI/CD secrets and cloud credentials. Assume any secrets that were accessible to GitHub Actions runners during the campaign window are compromised. Rotate AWS keys, Azure service principals, GCP service accounts, npm tokens, and Docker auth configs.
4. Pin GitHub Actions to commit SHAs, not tags. Using @v4 tags means a compromised action maintainer can silently push new code. Pinning to a full SHA prevents this class of supply chain hijack.
5. Restrict runner outbound network access. CI runners have broad outbound internet access by default. Implement egress filtering on self-hosted runners or use GitHub-hosted runner network restrictions to limit C2 communication.
6. Monitor for the Megalodon IoCs: C2 at 216.126.225.129:8443, commit author emails [email protected] and [email protected], and the campaign ID megalodon. Check for @tiledesk/tiledesk-server versions 2.18.6–2.18.12 in your dependency trees.

The Sable Angle

We've tracked the evolution of supply chain attacks for years — from vulnerable npm packages to CI/CD pipeline poisoning. Megalodon represents a new velocity frontier: 5,561 repositories compromised in six hours, with a propagation path from GitHub to npm that turns a single poisoned workflow into a package-registry-scale incident.

This is exactly the kind of threat that Sable's offensive security team stress-tests for enterprises daily. If your CI/CD pipeline is a production asset (and it is), it deserves production-grade security controls — branch protection, egress monitoring, secret rotation, and workflow auditing. The blind spot isn't your application code. It's the YAML files nobody reviews. Talk to us about hardening your pipeline before the next Megalodon lands in your repositories.