Three separate supply-chain incidents landed in the news cycle this week. None of them are unrelated — they're all variations of the same lesson: credentials are the new perimeter, and we keep losing them in transit.
I want to walk through what actually happened, what's verified versus rumoured, and why the Laravel-Lang one in particular should make every PHP shop in the region check their composer.lock before Monday.
| Incident | Date | Blast radius | Status |
|---|---|---|---|
| Megalodon | 18 May | 5,561 GitHub repos / 5,718 commits in ~6 hours | Confirmed (4 sources) |
| Robinsons (SG) | 21–22 May | Listed on Payload leak site | Claim only — unconfirmed |
| Laravel-Lang | 22–23 May | 4 Composer packages, 700+ tags rewritten | Confirmed (4 sources) |
1. Megalodon: 5,561 GitHub repos backdoored in six hours
On 18 May 2026, between roughly 11:36 and 17:48 UTC, an automated campaign — now tracked as Megalodon — pushed 5,718 malicious commits into 5,561 public GitHub repositories. StepSecurity caught the pattern first; SecurityWeek and The Register followed up with the same timeline.
The actors used throwaway accounts with eight-character random usernames and forged commit identities like build-bot, auto-ci and pipeline-bot — author emails [email protected] and [email protected]. Commit messages were boring on purpose: "ci: add build optimization step", "chore: optimize pipeline runtime". The kind of commit nobody reads.
The payload was a base64-encoded bash block injected into .github/workflows/ YAML, exfiltrating CI secrets, cloud credentials, SSH keys, OIDC tokens and any source-code secrets the runner could see, all the way out to a C2 at 216.126.225.129:8443.
The most uncomfortable detail comes from Hudson Rock's attribution work: more than a third of the unique GitHub usernames hit in this campaign were direct matches against machines already infected by commodity infostealers. Translation: a lot of "supply-chain attack" headlines really are "someone reused their GitHub password on a cracked Photoshop installer" headlines.
2. Robinsons listed on Payload's leak site
This one hit closer to home. On 21 May 2026 the ransomware group Payload added "Robinsons" to its public leak site; the entry was picked up by the ransomware.live Singapore tracker the following day. Robinsons is the 1858-founded department-store brand that most readers in Singapore grew up with — even though the high-street retail footprint has shrunk dramatically over the last few years.
I want to be careful here, because at the time of writing there is no public confirmation from Robinsons itself, no PDPC notification I can find, and no mainstream Singapore newspaper has run the story yet. A leak-site listing is a claim, not a confirmation — these groups have been wrong before, and they sometimes recycle old data to pad their reputation.
What we can say with confidence: Payload has been actively listing Singapore-based victims in 2026, including HOPPECKE's local subsidiary earlier in the month. If you do business with Robinsons or hold integration credentials for any of their systems, today is a reasonable day to assume the worst and rotate.
3. Laravel-Lang: every tag rewritten, credentials walked out
The third one is the one I lost sleep over, because RECATOOLS itself is a Laravel application.
Starting around 22 May 2026, four Composer packages under the laravel-lang/ namespace — lang, attributes, http-statuses, and actions — had more than 700 version tags rewritten in rapid succession. Aikido spotted the unusual tag pattern; Snyk and The Hacker News independently confirmed the payload analysis. Bleeping Computer has the cleanest narrative summary.
The clever bit — and the part that makes this so dangerous — is the attack vector. The attacker didn't push a new release. They abused GitHub's behaviour that lets version tags reference commits from a fork of the same repository, then pointed legitimate-looking tags at commits inside a fork they controlled. Composer happily resolved the new tags. The malicious file looked routine: src/helpers.php, with two helper functions named laravel_lang_locale() and laravel_lang_fallback(). Both functions are decoys — they do nothing useful.
The real payload was that helpers.php got wired into composer.json's autoload.files entry. That means it runs on every autoload — every CLI command, every web request, every php artisan invocation. It pulls a cross-platform second stage from C2 and then walks the host hoovering up cloud keys, Kubernetes config, Vault secrets, CI/CD tokens, SSH material, .env files, browser data, password-manager vaults, crypto wallets, messaging tokens. The lot.
Packagist has since taken the malicious versions down. If you ran composer install or composer update against the affected packages between 22 and 24 May, assume credential exposure on that host and rotate every secret it could see.
The thread that ties them together
Three different attacks, three different blast radii, one shared root cause: credentials sitting in places they shouldn't be sitting.
Megalodon worked because GitHub PATs were stolen off developer laptops by infostealers months ago and the owners never noticed. Laravel-Lang worked because somebody in the package's release chain had a credential the attacker could use to retag commits. The Payload group works because Singapore mid-market retailers, like mid-market retailers everywhere, still run VPN appliances with reused admin passwords.
None of this is new. The 2026 version is just faster — automation has compressed the gap between "credential leaks" and "5,000 repos backdoored" from weeks to hours. Defence has to compress in the same direction: short-lived tokens, fine-grained scopes, OIDC for machine-to-machine wherever possible, and treating any long-lived secret as a liability that costs you something to keep around.
I'll update this post if any of the three develops further. If you spot something I got wrong, please email me — I'd rather correct it on Monday than carry the error into next week's roundup.
