An Attacker Spent Friday Night Rewriting 700 Git Tags Inside Laravel Lang—Every composer install Since Has Been Quietly Shipping Your AWS Keys, GitHub Tokens, and Crypto Recovery Phrases to flipboxstudio.info

Key Takeaways

• An attacker compromised one organizational credential for laravel-lang on GitHub and rewrote every existing tag in four repositories on the night of May 22, 2026.
• Aikido confirmed 233 backdoored versions across three repos; Socket put the number closer to 700 once historical tags were counted.
• The PHP dropper autoloaded by Composer pulled a Windows binary called DebugElevator from flipboxstudio.info that exfiltrated AWS keys, GitHub tokens, Slack tokens, Stripe secrets, SSH keys, .env files, JWTs, Kubernetes secrets, Vault tokens, and cryptocurrency recovery phrases.
• Symbols left in the binary referenced both a username—Mero—and the string "claude," suggesting AI assistance during development.
• Packagist removed the malicious versions and temporarily unlisted the affected packages on May 23.

What Got Backdoored

Laravel Lang is a third party localization toolkit. It is not maintained by the official Laravel team, but it has shipped translations into roughly seventy five languages for more than a decade and is a default install on a meaningful slice of new Laravel projects. The compromised repositories on GitHub were laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes, and possibly laravel-lang/actions.

Aikido, which broke the story on May 23, reported 233 confirmed malicious versions across three of those repositories. Socket independently estimated the historical impact closer to 700 versions after counting every tag the attacker had rewritten, including releases that were nearly a decade old. The discrepancy comes from how each scanner counted: Aikido looked at currently published artifacts, Socket walked the git history.

The laravel-lang/lang package alone has 502 git tags. Every one of them was repointed.

How Did the Attacker Get In?

The forensics so far point to one compromised organizational credential. No source files were modified. No pull request was reviewed and merged. No package was published to Packagist directly. The attacker did something that, on the surface, leaves the repository looking untouched: they took every existing git tag in each repository and quietly repointed it at a fresh commit that they controlled.

Composer, the PHP package manager, resolves version constraints by reading the tags on the upstream GitHub repository. When a developer ran composer install or composer update any time between 22:32 UTC on May 22 and the moment Packagist began purging on May 23, Composer dutifully fetched the tag the developer asked for and got the attacker's commit instead of the original code.

Lockfile pinning did not help. The tag rewrite happened on the upstream side, so even projects with a composer.lock file got the malicious version when CI ran a fresh install. The only developers who escaped were the ones who had already cached the original tag locally and never re ran the resolver against the upstream.

What Did the Malicious Commit Do?

Each rewritten tag added a single PHP file at src/helpers.php that Composer autoloads on install. The helper called out to flipboxstudio[.]info and pulled down a secondary payload. On Windows hosts—the most likely environment for developer laptops running PHP via WSL or XAMPP—the secondary payload was a Windows executable the attacker named DebugElevator.

DebugElevator is a credential stealer in the modern, "vacuum everything that smells like a secret" tradition. It targets Chromium based browsers including Chrome, Brave, and Edge, but the payload reaches well beyond browser cookies. The exfiltration list includes:

• AWS access keys and session tokens
• GitHub personal access tokens and OAuth tokens
• Slack and Stripe API secrets
• Database connection strings and credentials
• JWT signing keys and session tokens
• SSH private keys
• Cryptocurrency wallet recovery phrases and seed files
• Cloud provider credentials beyond AWS—Google Cloud service account JSONs, Azure tenant credentials
• Kubernetes kubeconfig files and Vault tokens
• CI and CD pipeline secrets
• Browser saved logins and autofill data
• Browser extension stores for password managers
• VPN configuration files
• .env files anywhere on the filesystem

The PDB path the attacker left inside the binary referenced both a username—Mero—and the string claude. The presence of an AI coding assistant string in a malware binary is not, in itself, an attribution. It is a recurring pattern in 2026: the npm worm Shai-Hulud also persisted itself inside Claude Code's settings directory earlier this month, and TeamPCP's TanStack supply chain attack carried similar artifacts. AI tooling is becoming a load bearing component of opportunistic supply chain attacks because it lowers the per attack engineering cost.

Why Did Composer Trust Rewritten Tags?

Composer's default behavior is to resolve a version constraint to the latest tag on the upstream repository that matches the constraint, then check out the commit that tag points to. There is no signature verification on the commit. There is no comparison against a previously seen commit hash for the same tag. As long as GitHub returns a tag and a commit, Composer treats them as authoritative.

Git itself does have a mechanism to detect rewritten tags—when you fetch and a remote tag has been forced to a different commit, git fetch warns about it. But that warning fires in the developer's shell, not in Composer's network layer. Composer treats the tag resolution as opaque and never surfaces the divergence.

The same trust model is what made npm's Shai-Hulud campaign work earlier this year, and what makes the broader supply chain category so productive for attackers. Package managers were designed around the assumption that maintainers do not change history. When that assumption breaks, every downstream build of every project that pinned a tag gets a fresh dose of malicious code on the next install.

What To Do If You Run Laravel

First, search your composer.json and composer.lock files for any of the four compromised packages: laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes, laravel-lang/actions. If you find them, treat any system that ran composer install or composer update between 22:32 UTC on May 22 and midday on May 23 UTC as compromised.

Second, audit network logs—your laptop's, your CI runner's, your container images'—for any outbound connection to flipboxstudio.info. That domain is the canonical indicator of compromise. Aikido and Socket both report active DNS resolution for it as of disclosure.

Third, rotate. AWS access keys, GitHub personal access tokens, Slack and Stripe API keys, database credentials, SSH host and user keys, any signing keys, any JWT secrets, any cryptocurrency wallet keys that lived on the compromised machine. If the machine logged into a password manager during the exposure window, rotate the master password and any sessions the manager had cached. Bitwarden, 1Password, and LastPass browser extensions are all explicitly named in DebugElevator's exfiltration list.

Fourth, purge the cached package versions. The malicious tags were removed from Packagist but they still exist in your local vendor/ directory, your Composer cache at ~/.composer/cache, and any Docker image layers that were built during the window. composer clear-cache, rebuild affected images, and confirm composer install now resolves to the cleaned versions.

Why Email Inboxes Are Now a Supply Chain Target

Credential stealers like DebugElevator and REMUS have shifted their focus from password databases to session cookies and email tokens. The reason is straightforward: an authenticated session bypasses MFA, device verification, and risk based authentication, while a stolen password still has to clear those checks. Gmail and Outlook session cookies are the highest value items on any compromised developer machine—they unlock 2FA recovery flows for every other account the developer owns.

The same vector explains why the next wave of phishing is targeting developer email accounts. Once an attacker has access to your Gmail, they can read the verification codes the rest of your infrastructure sends you, including the rotation emails the security team sends after a supply chain incident. The Storm infostealer already proved that server side decryption of stolen browser cookies works against Gmail. DebugElevator's design follows the same template.

For everyone else, the lesson is that the trust boundary of an email inbox does not stop at the inbox. The marketing pixels that report your read state are the same mechanism that allows attackers to verify a stolen session is still alive. The same image fetch that tells a vendor when you opened their pitch tells an attacker that the cookie they stole on Friday night is still good on Monday morning.

The Bigger Pattern

May 2026 has been a brutal month for package ecosystems. TanStack got hit with 84 malicious packages through a stolen OIDC token on May 11. Three malicious versions of node-ipc landed on May 14. The AntV burst on May 19 dropped more than 300 malicious package versions in twenty two minutes. Laravel Lang followed on May 22 with a 700 version rewrite of historical tags.

Four distinct supply chain campaigns in eleven days, hitting npm, PyPI, and now Composer. Each one used a slightly different initial access vector—stolen OIDC token, compromised maintainer credential, account takeover via phished email. Each one ended the same way: credentials and tokens exfiltrated to attacker controlled infrastructure within minutes of the package being installed.

For organizations that depend on a software bill of materials and a continuous monitoring posture, the operational tempo is the new normal. The question is no longer whether a dependency will get backdoored this month but which one, and whether your detection catches the install before the credentials leave.