Megalodon: 5,561 GitHub Repositories Compromised in 6 Hours

On May 18, 2026, between 11:36 and 17:48 UTC, a campaign dubbed Megalodon compromised 5,561 GitHub repositories in a window of just six hours. Attackers pushed 5,718 malicious commits at a rate of roughly 1,000 commits per hour, injecting GitHub Actions workflows designed to exfiltrate CI/CD credentials to a command-and-control server at 216.126.225.129:8443. No individual developer accounts were compromised; the primary vector was the impersonation of automated identities, exploiting the implicit trust that CI/CD ecosystems grant to commits signed by bots.

The Speed That Makes Malicious Commits Invisible

The Megalodon campaign reached a scale that makes manual code review impractical. In six hours, attackers generated nearly six thousand commits distributed across more than five thousand repositories. According to SafeDep, the distribution by forged email shows 2,878 commits from build-system@noreply.dev and 2,841 from ci-bot@automated.dev. This symmetry suggests a balanced, automated infrastructure, not a series of manual actions.

The identity forgery technique exploits a structural characteristic of the GitHub ecosystem: commits can carry any username and email, and APIs do not verify consistency with a real profile. Both sources report that API calls for author and committer returned null fields, indicating no linked legitimate account. In practice, maintainers saw commits apparently signed by system bots, with names like build-bot, auto-ci, ci-bot, pipeline-bot.

Implicit trust in bot commits is the core of the problem. CI/CD pipelines are designed to automatically execute code from automated identities; there is no room for human code review at these speeds. When an attacker manages to impersonate that class of identity, the system has no verification levers.

The Backdoor Mechanism: SysDiag and Optimize-Build

The payloads analyzed by SafeDep present two variants with complementary functions. SysDiag is designed for mass compromise: it triggers on push and pull request events, collecting environment secrets as quickly as possible. Optimize-Build is instead targeted: it uses the workflow_dispatch trigger, which allows manually starting a workflow without new code being pushed.

The workflow_dispatch trigger has a critical side effect. GitHub Actions anti-recursion rules prevent the GITHUB_TOKEN from triggering new workflows in response to events generated by workflows themselves. But workflow_dispatch is explicitly excluded from this block: a manually triggered workflow can in turn trigger other workflows. Attackers exploited this exception to maintain dormant persistence in target repositories, ready to be activated later.

Permissions requested by the malicious workflows include id-token: write for OIDC authentication to cloud providers, and actions: read for access to pipeline metadata. The combination allows both exfiltration of short-lived tokens and reconnaissance of the victim's CI/CD infrastructure.

The Tiledesk Case: When the Repository Poisons the Registry

"The attacker never touched the npm account. They compromised the GitHub repository, and the maintainer published from the poisoned source without realizing it." — SafeDep analysis

The most documented case of the campaign involves Tiledesk, an open-source project with nine repositories hit. Commit acac5a9 on May 18, 2026 introduced the malicious payload into the source code. Maintainer eljohnny, with email giovanni@tiledesk.com, subsequently published versions 2.18.6 through 2.18.12 of @tiledesk/tiledesk-server to the npm registry, unaware that the source code had been compromised.

SafeDep published the diff between clean version 2.18.5 and backdoored 2.18.12, showing the payload insertion into build routines. This chain — poisoned repository, unwitting maintainer publication, automatic distribution via registry — is the paradigm of the modern supply chain attack. The maintainer was not personally compromised; they simply did what they always did, on source that was no longer authentic.

Other documented organizations with affected repositories include Black-Iron-Project (eight repositories) and WISE-Community. SafeDep provides the complete list of compromised repositories, with timestamps and commit identifiers.

What to Do Now

For GitHub repository maintainers, the first action is to check for suspicious workflows with workflow_dispatch triggers inserted between May 18 and 19, 2026. SafeDep has published complete IOCs including filename patterns SysDiag.yml and Optimize-Build.yml, plus the C2 address 216.126.225.129:8443.

It is necessary to audit organization logs for commits with author/committer returning null from GitHub APIs, or with emails from the noreply.dev and automated.dev domains. These are precise indicators of the documented campaign.

For teams publishing to npm or other registries, verification must extend to versions published starting May 18, 2026. The Tiledesk case demonstrates that compromised source code can propagate to the registry without compromise of the maintainer's account. Comparing local build checksums against those in the remote repository is a specific control for this vector.

Reviewing Actions workflow permissions is another direct action. Workflows requesting id-token: write and actions: read must be limited to only the files that actually need them, and merging PRs that modify these permissions requires explicit review.

What We Know and What Remains Dark

The source does not specify the initial access vector: how attackers obtained credentials to push to 5,561 repositories remains the primary dark spot. It does not emerge whether this was a mass account compromise, a leak of personal access tokens, exposed deploy keys, or a completely different mechanism.

No infrastructure overlaps emerge linking the campaign to known threat actors at this time. The real identity or group behind Megalodon is not identified in available sources. The C2 server 216.126.225.129:8443 is documented in technical analyses, but the dossier does not specify whether it has been sinkholed or remains active.

The figure of 5,561 repositories refers to unique target repositories with commits pushed; the source does not document how many of these workflows were actually executed, nor the extent of cloud compromise beyond initial exfiltration. Neither source reports an assigned CVE for the vulnerability, nor token revocations or blocks by GitHub.

The dossier does not document whether the backdoored npm versions have been deprecated or removed from the registry.

Why It Matters

The Megalodon campaign exemplifies a structural shift in the threat ecosystem. No longer compromise of individual developer accounts, but systematic exploitation of a class of identities — CI/CD bots — that the modern development flow treats as trusted by design. The execution speed, roughly 1,000 commits per hour, renders manual controls obsolete by construction.

The Tiledesk case demonstrates that the risk perimeter extends from repository to registry without a seam. The legitimate maintainer becomes an unwitting vector, and the signature of publication in the registry no longer guarantees source code integrity.

The pattern is replicable. Bot identities are not robustly verifiable by current APIs; the workflow_dispatch trigger provides a persistence channel that bypasses anti-recursion rules. As long as these characteristics remain structural, the attack surface persists.

According to the source, Ox Security researchers have characterized similar events as "the beginning of an endless wave or a tsunami of attacks." The phrasing is rhetorical, but the underlying datum is that CI/CD automation has created a class of unverifiable identities that attackers can impersonate at industrial scale. Megalodon is the quantified proof.

Information is based on the cited source and current as of publication.

Sources

• https://socfortress.medium.com/megalodon-attack-swallowed-5-561-github-repositories-92db9361328e
• https://safedep.io/megalodon-mass-github-repo-backdooring-ci-workflows/
• https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication#using-the-github_token-in-a-workflow