Home / Critical Brief / No. 004

Megalodon GitHub Supply Chain

CI/CD Credential-Theft Campaign That Poisoned 5,561 Repositories in 6 Hours

Pillar 01 · Verifiable Origin Code Provenance Identity & Auth
Incident date
2026-05-22
Published
2026-05-30
Authors
Lemma Critical Team
Related Pack
Pack AIncident Response

TL;DR

Megalodon is a CI/CD credential-theft campaign that abused stolen legitimate developer credentials to push spoofed commits to 5,561 GitHub repositories within 6 hours. Three firms pinpointed the origin and scope within five days, but detection cannot change what the receiving sides accept. The spoofed commits passed through legitimate processes and were accepted as legitimate. The gap is that commit author and repo owner authentication form a chain never independently verified at each stage. Detection and pre-execution attestation are complements, not substitutes.

Incident Overview

  • Campaign name: Megalodon
  • Disclosure / reporting: Safe Dep, Ox Security, Hudson Rock
  • Scale: 5,561 GitHub repositories, 5,781 malicious commits, within 6 hours
  • Principal payload path: @tiledesk/tiledesk-server, the npm package backing an open-source live-chat / chatbot platform, versions 2.18.6 through 2.18.12 (published 2026-05-19 through 2026-05-21). The last clean release is 2.18.5
  • Exfiltrated: AWS secret keys, Google Cloud access tokens, AWS / GCP / Azure metadata, instance role credentials, SSH private keys, Docker / Kubernetes configurations, Vault tokens, GitHub tokens, Bitbucket tokens
  • Attacker GitHub account characteristics: Random usernames (rkb8el9r, bhlru9nr, and similar), pushing via compromised PATs or deploy keys
  • Spoofing characteristics: Reuse of four author names — build-bot / auto-ci / ci-bot / pipeline-bot — paired with seven kinds of commit messages dressed up as routine CI maintenance
  • Core: The structural failure was that commit author identity and repository owner authentication form a chain of trust never independently verified at each stage, so spoofed commits made with stolen legitimate credentials were accepted as “a legitimate developer’s legitimate commit.”

Timeline

  • 2026-05-19: tiledesk-server 2.18.6 (the first backdoored release) is published to npm
  • 2026-05-19 to 2026-05-21: 2.18.7 through 2.18.12 are released in succession, all backdoored
  • 2026-05-22: Safe Dep and Ox Security each publish independent technical analyses
  • Around 2026-05-22: Hudson Rock reports the infostealer-origin path. The attacker GitHub usernames associated with affected repositories match infostealer-infected machines in 33% of cases directly, with additional matches via email address

Note: Names, package names, and versions are based on the primary analyses by Safe Dep, Ox Security, and Hudson Rock and on public npm registry information. Each implementation’s remediation status varies over time, so consult the latest information.

Attack Vector

  1. Initial compromise: Infostealer infection. GitHub credentials (PATs, deploy keys, session tokens) are stolen from individual developers’ personal machines
  2. Credential routing: Using the stolen credentials, the infected developer’s direct push access into the GitHub repositories they hold permission to is taken over
  3. Mass push: An automated script pushes 5,781 commits dressed up as routine CI maintenance to 5,561 repositories within 6 hours. Each commit uses one of the spoofed author names build-bot / auto-ci / ci-bot / pipeline-bot
  4. Persistence vehicle: The Megalodon payload is bundled inside GitHub Actions workflow files (.github/workflows/), replacing the original workflow with an attacker-controlled “Optimize-Build” workflow
  5. Downstream amplification: When a repository owner merges the malicious commits, the CI/CD pipeline executes Megalodon, exfiltrates AWS / GCP / Azure / Vault credentials from the CI environment, and propagates further
  6. Impact realization example: Without ever touching the npm account behind @tiledesk/tiledesk-server (eljohnny), the GitHub repository was compromised and the maintainer unknowingly published malicious versions 2.18.6 through 2.18.12

Structural Analysis

This incident is a representative case of a structure in which, across commit / release / CI/CD pipeline stages, commit author identity and repository owner authentication are not independently verified, yet form a chain. The attacker had only to seize one stage (an individual developer’s credentials) for all downstream stages (npm publication, CI/CD execution, malicious distribution with no obvious culprit) to follow legitimate processes.

The primitive differs from Brief 001 and Brief 002 (cross-chain message trust on bridges) — the target here is a code commit, not a cross-chain message — but the underlying structure is shared: the chain of trust is not independently verified at each stage. The earlier Briefs concerned the config and observation layers; this incident concerns the authentication layer of commit author and repo owner. Both share the structure of absent trust-boundary verification.

The structure differs from Brief 003 (Starlette / BadHost) in that the present case concerns the origin of code commits while Brief 003 concerns the authentication of HTTP requests, but the two are adjacent: credential concentration and authentication bypass are shared points of discussion.

The detection–proof gap

In this incident, three firms — Safe Dep, Ox Security, and Hudson Rock — independently analyzed the campaign and identified the cause (infostealer origin) and the scope (5,561 repositories, four spoofed author names) within five days. The detection layer contributed to shaping the contours of the event and made the problem visible across the industry. This Brief does not deny the role of detection vendors.

But detection does not change what the receiving sides (GitHub, npm registry, CI/CD pipelines) accept. The attacker’s spoofed commits were pushed through the legitimate commit signing process, and the registry accepted publication under what looked like a legitimate maintainer account. Detection limited the spread of damage, but it could not stop acceptance itself.

For the purposes of establishing in regulatory filings or administrative proceedings whether “the commit was legitimate / the publication was legitimate,” detection scores carry no independent attribution residue. Pre-execution attestation stands in a complementary, not substitutive, relationship to detection. The requirement is a design that embeds, on each commit, an independently verifiable cryptographic proof that “this was generated by a legitimate individual developer under legitimate authority” — and that the CI/CD pipeline verifies the proof before building the commit. GitHub’s signing commits (GPG signing) is conceptually in this direction, but as long as the key itself sits on the machine, the structure of seizure via infostealer remains. What is required is the direction of fixing commit author identity as a ZK proof without exposing the key.

For the detection-vs-attestation thesis, see “The last layer left for cyber defense in the age of AI” (Lemma, 2026-05); for verifying before the action, see “Proof-as-Auth: sign in without ever sending your key” (Lemma, 2026-05).

Response and Industry Developments

  • Safe Dep: Identified and disclosed the Megalodon payload path in tiledesk-server
  • Ox Security: Independent analysis of the Megalodon CI/CD malware (lead researcher: Bustan)
  • Hudson Rock: Confirmed the infostealer-origin path with empirical data (33% username match)
  • GitHub / npm: During the same period, npm introduced “graded releases” (2026-05-22), adding a step so that leaked tokens alone cannot publish a package (a related but separate matter)
  • npm registry: An industry-wide cross-organizational process for early detection and rollback of malicious publications under legitimate maintainer accounts is being put in place

On the relationship with TeamPCP: Just before Megalodon surfaced, TeamPCP had announced an “open-sourcing” of the Shai-Hulud supply-chain worm and a “supply-chain attack competition,” but Ox Security’s Bustan has stated that no evidence linking Megalodon to TeamPCP has been found.

Lemma’s Analysis

Lemma’s design answers this incident’s gap — absent independent verification of commit author and repo origin — by verifying each commit’s provenance as a proof before the CI/CD pipeline builds it.

  • Origin provenance binding: At each stage of commit / release / CI/CD pipeline, an independently verifiable cryptographic proof that “this commit / artifact came from a legitimate origin” is fixed.
  • Key-less proof: Unlike GPG signing, the key itself does not sit on a machine that can be seized, so even if infostealers steal credentials they cannot generate the proof for a spoofed commit.
  • Proof-as-auth before the action: Commit author identity is fixed as a ZK proof, verifying legitimate authority before the pipeline builds or merges.
  • Complement to detection: After-the-fact analysis like the three firms’ scoping and a proof that fixes provenance before acceptance function as a two-stage configuration, not opposing approaches.

This is the design philosophy of “cryptographically valid ≠ provenance correct” — the core of the verifiable-origin category — and it complements, rather than replaces, the detection layer.

For the design and its scope, see Pillar 01 — Verifiable Origin and Trust402.

Sources

About distribution

This material is a structured analysis of public information; it is not an audit, diagnosis, or recommendation for any specific organization.

(c) 2026 FRAME00, INC. — Built for decisions that matter.

Related Briefs
See all 13 in Code Provenance
No. 048 · 2026-06-12

TrapDoor Plants Hidden Directives in AI Assistant Instruction Files Across npm, PyPI, and Crates.io

TrapDoor, disclosed by Socket, is a credential-stealing campaign whose distinctive technique plants invisible directives…

Code Provenance Agent InfrastructureAI Decision Integrity
Brief →
No. 038 · 2026-06-09

IronWorm

When Stolen Credentials Become Publishing Authority (npm Self-Propagating Implant)

Code Provenance Identity & Auth
Brief →
No. 030 · 2026-06-06

Stripe's Trusted API Infrastructure Repurposed to Deliver Card-Skimming Code and Store Stolen Data

Allowlists Trust the Domain's Identity, Not the Provenance of What It Carries

Code Provenance Identity & AuthData Provenance
Brief →
Citation

Cite this Brief

Lemma Critical Team. (2026).
"Megalodon GitHub Supply Chain — CI/CD Credential-Theft Campaign That Poisoned 5,561 Repositories in 6 Hours".
Lemma Critical Brief No.004. Lemma / FRAME00, Inc.
https://lemma.frame00.com/critical/briefs/004-megalodon-github-supply-chain/