On May 18, 2026, between 11:36 and 17:48 UTC, an automated campaign that researchers have named Megalodon pushed 5,718 malicious commits to 5,561 distinct GitHub repositories. Every commit did the same thing: it dropped a backdoored GitHub Actions workflow that exfiltrates secrets from each pipeline run. If you maintain a public repo with weak branch protection, you need to check your Actions directory tonight.

What happened

The attacker rotated through four forged author identities — build-bot, auto-ci, ci-bot, pipeline-bot — and seven commit messages, all mimicking routine CI maintenance. The pushes came from throwaway GitHub accounts with random 8-character usernames (rkb8el9r, bhlru9nr, lo6wt4t6) using compromised personal access tokens or deploy keys. SafeDep, which published the first detailed report, observed two payload variants:

  • SysDiag — the mass variant. Adds a new workflow file triggered on: push and on: pull_request, so it runs on virtually every repository event.
  • Optimize-Build — the targeted variant. Replaces an existing workflow with a workflow_dispatch trigger, creating a dormant backdoor the attacker fires on demand through the GitHub API. It trades reach for operational security — useful once you already hold a working GITHUB_TOKEN.

Each workflow carries a base64-encoded bash payload. Once a maintainer merges the commit, the payload executes inside the CI/CD runner and harvests everything it can reach.

Technical details

The payload’s collection list is broad. It scrapes CI environment variables, /proc/*/environ, and the PID 1 environment; AWS, GCP, and Azure instance-role credentials by querying IMDSv2 and the cloud metadata endpoints; SSH private keys; Docker and Kubernetes configs; Vault and Terraform credentials; and shell history. It grep-scans source for more than 30 secret regex patterns — API keys, database connection strings, JWTs, PEM private keys.

The most damaging item is the GitHub Actions OIDC token request URL and token. With that, the attacker can mint short-lived cloud identities through any trust relationship the repo was authorized for — turning a single poisoned workflow into direct cloud access. It also lifts GITHUB_TOKEN, GitLab CI/CD tokens, and Bitbucket tokens. Everything is shipped to a C2 server at 216.126.225[.]129:8443.

Because a stolen GITHUB_TOKEN can push further commits, the campaign behaves like a worm: one compromise feeds the next. As of May 21, the attacker’s ingest server had logged 575,352 stolen files and 449 GB of exfiltrated data.

The campaign is attributed to TeamPCP, the same crew behind the Trivy and Checkmarx KICS GitHub Action compromises and the recent TanStack, Grafana, OpenAI, and Mistral AI incidents. A May 23 Hudson Rock analysis traced the initial access cleanly: more than 33% of affected GitHub usernames matched machines already known to be infected by infostealer malware. The conclusion is blunt — these accounts were compromised because the developers behind them were running infostealers, and GitHub became the launchpad.

Impact

Any public repository with weak branch protection was a candidate. The blast radius is not the 5,561 repos themselves — it is every downstream project that consumes their artifacts and every cloud account reachable from a harvested OIDC token. @tiledesk/tiledesk-server was hit across nine repositories, with the payload bundled directly into a workflow file.

What to do right now

Audit .github/workflows/ in every repo for unexpected files or recently modified workflows, especially commits from author names like build-bot or ci-bot dated May 18. Grep your CI logs for outbound connections to 216.126.225.129. Assume any secret exposed to a compromised pipeline is burned: rotate cloud keys, SSH keys, registry tokens, and revoke OIDC trust relationships, then reissue them. Enforce branch protection and required reviews on every public repo, and pin third-party Actions to full commit SHAs rather than tags. Treat developer endpoints as part of your supply chain — an infostealer on a laptop is now a credible path to your cloud. npm has already invalidated all bypass-2FA granular tokens and is pushing maintainers toward Trusted Publishing; the same instinct applies here.

References