Megalodon: An Automated Campaign Backdoored 5,561 GitHub Repositories in Six Hours by Poisoning Their CI/CD Workflows

Megalodon is not an exploit — it is the abuse of the single most routine action in software development. In one six-hour window on May 18, an automated campaign pushed 5,718 malicious commits to 5,561 GitHub repositories, hiding base64-encoded payloads inside GitHub Actions workflow files and signing them as four plausible-looking CI bots. A maintainer who merges what reads as a 'build-bot' housekeeping commit runs the payload inside their own pipeline — and it scans for, and exfiltrates, every secret it can reach. The uncomfortable lesson: the .github/workflows/ directory is now a primary supply-chain attack surface, not a configuration detail.

TEL AVIV, ISRAEL — On May 18, 2026, an automated supply-chain campaign that researchers have codenamed Megalodon pushed 5,718 malicious commits to 5,561 GitHub repositories in a single six-hour window. The campaign works by injecting GitHub Actions workflow files that carry base64-encoded bash payloads; once a repository owner merges the commit, the payload runs inside that project's own CI/CD pipeline, scans the source code for more than 30 categories of secrets, and exfiltrates CI/CD secrets, cloud credentials, SSH keys, and OIDC tokens to a command-and-control server. To pass as routine activity, the operator forged four bot author identities — build-bot, auto-ci, ci-bot, and pipeline-bot — and rotated through seven commit messages that all mimic ordinary CI maintenance. The campaign was documented across the May 21-22 coverage cycle by The Hacker News, the application-security firm OX Security, and SafeDep, and no public reporting has tied it to a named threat actor.

What Happened

An Automated Campaign That Ran for Six Hours

The defining number in the Megalodon campaign is not the 5,561 repositories — it is the six hours. In a single window on May 18, 2026, the operation pushed 5,718 malicious commits across those repositories, a volume and velocity that is only possible because the campaign is automated end to end. There is no manual target selection and no human pacing the commits; the tooling enumerates repositories, generates the malicious change, forges the commit, and pushes it — at machine speed, across thousands of projects at once. That automation is the campaign's core capability and the reason it deserves attention beyond its raw scale. A human-paced attacker backdooring repositories one at a time is a containable problem. An automated one that can touch 5,561 of them in an afternoon is a structural one.

The Disguise — Four Bots and Seven Commit Messages

Megalodon's payload hides in plain sight. It injects GitHub Actions workflow files — the YAML files in a repository's .github/workflows/ directory that define its CI/CD automation — and inside them places a base64-encoded bash payload. The disguise lives in the metadata. Rather than push commits under an obvious or random identity, the operator forged four author names chosen to look like a project's own automation: build-bot, auto-ci, ci-bot, and pipeline-bot. The commits rotate through seven different commit messages, each written to read as unremarkable CI housekeeping. To a maintainer skimming a notification or a pull-request list, a commit from 'build-bot' adjusting a workflow file is exactly the kind of change the eye slides past. That is the point: Megalodon is engineered not to be caught at the moment of review.

Two Variants — SysDiag and Optimize-Build

Researchers documented two distinct payload variants. The mass variant, 'SysDiag,' adds an entirely new workflow file configured to trigger on every push and every pull request — maximizing the number of times the payload runs automatically once it is in place. The targeted variant, 'Optimize-Build,' is quieter and arguably more dangerous: instead of adding a workflow, it replaces an existing one and rewrites its trigger to workflow_dispatch, the GitHub Actions trigger that fires only when invoked deliberately through the GitHub API. That converts the compromised workflow into a dormant backdoor — one that does nothing visible until the operator chooses to fire it on demand. A repository that looks clean today because nothing has executed may still be holding an Optimize-Build backdoor waiting for its call.

Scope and Impact

What makes Megalodon more than a noisy commit spray is what the payload does once it runs. Inside the victim's pipeline it grep-scans the repository's source code against more than 30 regex patterns for secrets — API keys, database connection strings, JSON Web Tokens, PEM-encoded private keys, and cloud-provider tokens — and it specifically captures the GitHub Actions OIDC token request URL and token. That last detail matters. OIDC tokens are the mechanism by which a pipeline proves its identity to a cloud provider, so capturing one can let an attacker impersonate the pipeline's cloud identity rather than merely reusing a static key. A single merged commit can therefore expose not just the repository's secrets but the cloud accounts those secrets unlock.

Megalodon does not arrive in isolation. It lands in the same two-week window as a cluster of attacks on the developer-trust surface that The CyberSignal has tracked closely: GitHub's confirmation that the actor TeamPCP exfiltrated 3,800 internal repositories through a single poisoned VS Code extension, the Shai-Hulud npm worm now generating valid Sigstore provenance badges for its malicious packages, the copycat operator who pushed Shai-Hulud clones to npm within a week of TeamPCP leaking the source, and the pull_request_target 'pwn request' abuse that hit Grafana. Read together, these are not coincidences. They are independent operators arriving, in the same fortnight, at the same conclusion: the developer's toolchain is the softest path into everything downstream of it.

Several things about Megalodon are genuinely not known, and this account should not imply otherwise. Exposure is not the same as compromise: the 5,561 figure counts repositories that received a malicious commit, not repositories whose owners actually merged it, and how many merges occurred — and therefore how many pipelines actually ran the payload — has not been reported. The downstream victim count, whether any widely depended-upon repositories were among those hit, whether GitHub has removed all the malicious commits and notified maintainers, and whether the Optimize-Build dormant backdoors have been triggered are all open questions. And despite the campaign landing alongside TeamPCP's source-code extortion activity, no public evidence ties Megalodon to TeamPCP or to any named actor; it should be treated as a separate, unattributed campaign.

Response and Attribution

The immediate action for every engineering organization is an audit. Review recent commits to your repositories' .github/workflows/ directories and flag anything authored by build-bot, auto-ci, ci-bot, or pipeline-bot, along with any workflow file added or replaced in the May 17-19 window — looking specifically for workflow files that contain base64-encoded bash and for workflows that newly use a workflow_dispatch trigger you did not create. If any Megalodon-pattern commit was merged, treat every secret reachable from that pipeline as burned: rotate CI/CD secrets, cloud credentials, and SSH keys, review cloud audit logs for OIDC-token-based identity impersonation, and block outbound traffic from CI runners to 216.126.225[.]129. Going forward, the structural fix is to treat .github/workflows/ as the highest-trust path in the repository — require review and approval for every change to a workflow file, enforce branch protection and CODEOWNERS on the .github/ directory, pin GitHub Actions to allowlisted versions, and move to short-lived, tightly scoped OIDC cloud credentials so that a captured token is far less useful.

For SOC and threat-hunting teams, the Megalodon indicators — the command-and-control IP, the four bot author names, and the base64 workflow-payload pattern — are straightforward to hunt across GitHub organization audit logs, and base64 bash phoning home to a non-standard port (8443) is a detectable egress pattern; unexpected workflow_dispatch workflows should be treated as potential dormant backdoors. For CISOs, the harder takeaway is strategic. Megalodon is the third major developer-supply-chain campaign in two weeks, and it demonstrates that the economics have changed: a fully automated operation reached 5,561 repositories in six hours, and manual code review does not scale against that. The CI/CD workflow file has graduated into a Tier 1 attack surface, and supply-chain risk should be re-baselined accordingly — with investment in workflow-integrity tooling and CI/CD secret hygiene, not developer awareness alone.

The CyberSignal Analysis

Signal 01 — Megalodon Weaponizes the Merge, Not a Vulnerability

Most supply-chain coverage will lead with the 5,561-repository number, and the scale is genuinely striking. But the more important fact is what Megalodon does not require: a vulnerability. There is no CVE here, no exploit, no flaw in GitHub's code. The campaign works because it abuses a workflow — the single most routine action in software development, the act of a maintainer accepting a plausible-looking change. A commit from 'build-bot' adjusting a CI file is precisely the kind of thing a maintainer merges without a second look, and the moment they do, the payload runs inside their own pipeline. That is a fundamentally different problem from a patchable bug. You cannot patch the merge. Defending against Megalodon means changing how the highest-trust, least-scrutinized changes in a repository are reviewed — organizational and procedural work, not a software update.

Signal 02 — The .github/workflows/ Directory Is the Soft Spot

Every repository has a directory that is simultaneously the most powerful and the least reviewed: .github/workflows/. The files there define what runs in CI, with what permissions, with access to which secrets — and yet in most organizations a change to a workflow file passes through the same casual review as a change to a README, or less. Megalodon is built precisely around that asymmetry. Its entire method is to put a base64 payload into a workflow file and let normal, light-touch review wave it through. The editorial takeaway for engineering leaders is narrow and concrete: the .github/ directory deserves stricter controls than your application code, not looser ones — required reviews, CODEOWNERS, pinned actions, and a default assumption that an unexpected workflow change is hostile until proven otherwise.

Signal 03 — Automation Rewrote the Math

The reason Megalodon belongs in the same conversation as the GitHub/TeamPCP breach and the Shai-Hulud worm is not that they share an operator — there is no evidence they do — but that they share a conclusion. In a single fortnight, three independent operators each industrialized an attack on the developer-trust surface, and Megalodon is the clearest demonstration of what that industrialization means: 5,561 repositories touched in six hours by tooling that needs no human in the loop. Manual review — a maintainer carefully reading each commit — is the defense this campaign is designed to outrun, and at automation's scale it simply cannot keep pace. The defensive response has to be automated too: workflow-integrity scanning, secret-exposure detection, and machine-speed alerting on the developer pipeline. The era in which supply-chain security could rely on a careful human at the merge button is the era Megalodon just closed.

Sources