🤚 The Open-Palm Commit History
On May 18, 2026, between approximately 11:36 and 17:48 UTC — a window of just over six hours — an attacker operating under the creative pseudonym “build-bot” pushed 5,718 malicious commits across 5,561 GitHub repositories. The campaign, dubbed “Megalodon” by the security researchers at SafeDep who discovered it, injected poisoned GitHub Actions workflows designed to steal every credential that wasn’t welded to the floor.
The targeted secrets include:
- AWS, GCP, and Azure credentials
- SSH private keys and Docker/Kubernetes configurations
- API keys, database connection strings, and CI/CD tokens
- GitHub Actions and GitLab CI/CD secrets
- Dozens of other environment variables that your
.envfile told you were safe
The attack operated through two email addresses linked to the build-bot accounts — one pushing 2,878 commits, the other 2,841 — in a display of parallelism that would be impressive if it weren’t terrifying.
👐 The Two-Handed Autopsy
The technical elegance of Megalodon deserves reluctant admiration. The attacker injected two types of payloads:
Type 1: Brand-new workflow files triggered on every push and pull_request event — meaning every subsequent contributor to those 5,561 repositories would unknowingly activate the credential harvester.
Type 2: Modified existing workflow files with a workflow_dispatch trigger — creating dormant backdoors that could be activated later via the GitHub API using previously stolen tokens. This is the supply chain attack equivalent of installing a light switch in someone’s house and coming back later to flip it.
The workflow_dispatch trick is particularly nasty because it bypasses GitHub’s anti-recursion protections. GitHub, reasonably, prevents workflows from triggering other workflows to avoid infinite loops. But workflow_dispatch is exempt from this rule because it’s designed for manual triggering. The attacker simply automated the “manual” part. The safety feature became the attack surface. As is tradition.
The compromise was first noticed when SafeDep researchers identified poisoned versions of Tiledesk, an open-source live chat and chatbot platform, published between May 19-21. The attacker had accessed the Tiledesk maintainer’s GitHub repository — without compromising their NPM account — and the maintainer unknowingly published packages from the poisoned source code. The malware rode the legitimate release pipeline like a first-class passenger with a forged ticket.
🌿 The Gentle Awakening
If you’ve been keeping score at home, 2026 is shaping up to be the Year of the Supply Chain Attack, and we are only in May. Three weeks ago, the Shai Hulud attack compromised hundreds of signed npm and PyPI packages by poisoning the cryptographic verification process itself. A week before that, GitHub confirmed 3,800 internal repositories were stolen via a malicious VS Code extension. And now Megalodon has demonstrated that you don’t even need to compromise a package registry — you can just commit directly to the source.
The escalation pattern is unmistakable:
- 2024: Attackers poison packages on registries
- 2025: Attackers poison the signing process
- 2026: Attackers poison the repositories themselves, and the legitimate maintainers distribute the malware for free
Each step removes a layer of trust. We are rapidly approaching a world where the only safe dependency is one you wrote yourself, and even then, your CI/CD pipeline might disagree.
👑 The Gold-Leaf Reckoning
The phrase security researchers are using is “a new supply chain attack era,” and for once the dramatic language is underselling the situation. 5,561 repositories were compromised in six hours. That’s roughly 15 repositories per minute. The attacker didn’t need sophisticated tooling. They needed two email addresses, some GitHub API knowledge, and the understanding that most open-source maintainers don’t have security teams — they have day jobs.
The fundamental problem is architectural. GitHub Actions workflows run with the permissions of the repository, and those permissions often include access to secrets that were configured once, three years ago, by an engineer who has since left the company. The attack didn’t exploit a bug in GitHub. It exploited the design of GitHub. The platform is functioning exactly as intended, and that is the problem.
Every organization running production workloads that depend on open-source repositories — which is to say, every organization — now has to audit whether any of the 5,561 compromised repos appear in their dependency tree. If they do, the credentials stored in your CI/CD environment may already be in someone else’s hands. The secrets you rotated last quarter? Rotate them again. The workflow files you haven’t reviewed since onboarding? Review them now.
“The commit message said ‘chore: update dependencies’ and the dependencies updated were your AWS keys, your SSH keys, and your faith in the open-source ecosystem. The PR was auto-merged.” — The Slap of Wisdom DevSecOps Bureau, currently running git log –all with the lights on