Hackers Just Poisoned 233 Versions of Laravel-Lang Across 700 GitHub Repos. If You Run a Composer-Based SaaS, Here's the 30-Minute Audit.

On May 22, 2026, researchers disclosed a supply chain attack against the Laravel-Lang ecosystem (a set of widely used translation packages for Laravel applications). The attacker compromised more than 700 GitHub repositories, rewrote version tags to point at commits in a malicious fork, and injected a 5,900-line PHP credential stealer that loads automatically through Composer's autoloader. By the time the attack was detected, 233 package versions were poisoned and available on Packagist.

If you run a Laravel-based SaaS and you ran composer update in the last few days without checking, you need to read this.

What the tag-rewrite attack actually looks like

The npm postinstall worm from last week (the one that harvested API keys from CI/CD pipelines) got most of the coverage. This attack is different in a way that matters.

In a typical package compromise, the attacker modifies a package's published source code on the registry. This attack moved faster: the attacker rewrote all the affected tags in a single 15-minute window, giving defenders almost no time to intervene before malicious packages were available on Packagist. Your composer.lock records a content hash; if the package changes, the hash changes, and you'll see a drift warning. That's the defense everyone knows about.

The Laravel-Lang attack used tag-rewriting. The packages themselves were not modified at the registry level. Instead, the attacker gained write access to the GitHub repositories that Composer references for version resolution, then moved the version tags (v5.12.0, v5.13.1, and so on) to point at commits in a malicious fork they controlled. Packagist picked up the new tag targets on its next sync.

The result: a fresh composer require or composer update pulled malicious code that matched a tag your lockfile trusted. Your hash-based integrity checks did not help because the hash matched the malicious commit, not the legitimate one.

The payload is not subtle

The fetched code is a 5,900-line PHP file organized into 15 specialist collector modules. It goes after:

• Environment files (.env, .env.local, .env.production)
• Database credentials in config/database.php
• Laravel app keys and encryption keys
• SSH private keys in ~/.ssh/
• Stored browser credentials and cookies (cross-platform: Windows, macOS, Linux)
• AWS credential files
• Any Stripe, Twilio, or API keys in your config directory

After collecting, it AES-256 encrypts everything and exfiltrates to flipboxstudio[.]info/exfil. The domain is now sinkholed, but if your instance ran the payload before the sinkhole was in place, the data left.

Why solo-operated SaaS is the specific target surface

I want to be direct about who is most at risk here.

Enterprise Laravel shops typically have a few things that slow this down: automated dependency audit in CI, a team reviewing vendor advisories, and a release process that doesn't go straight from composer update to production. Solo operators running Laravel-based products often don't have any of those. composer update && git push && deploy is a completely normal workflow when you're the only engineer.

The attacker's payload runs at PHP autoload time: which is every request. If you ran an affected version on a production server with your .env in a standard location, the exfil happened on the first page load.

The 30-minute audit

Here's what I'd do right now if I were running a Composer-based SaaS.

Step 1: Check if you have the affected packages. The compromised repositories are in the laravel-lang organization. Run:

composer show | grep laravel-lang

If you have anything from laravel-lang/*, pull up your composer.lock and check the exact commit SHA recorded for those packages. Cross-reference with the affected version list published by the Aikido Security advisory (linked in sources below).

Step 2: Check when you last updated. If your lockfile was updated between May 20 and May 23, treat those packages as suspect until confirmed clean.

git log --oneline composer.lock | head -5

Step 3: Rotate immediately, don't investigate first. If there's any chance you pulled an affected version in production, rotate your credentials before you do anything else. Your .env-sourced database password, your Stripe secret key, your Laravel APP_KEY: all of it. Investigation takes time. Rotation takes 10 minutes and you can investigate on a clean credential set.

Step 4: Lock your Composer installs to SHAs in CI. After cleanup, add --no-dev --prefer-dist --no-interaction to your CI install command and consider pinning critical packages to specific commits via composer.json's source reference. It's not a perfect defense but it changes the attack surface.

Step 5: Check for outbound traffic to flipboxstudio[.]info. Pull your server access logs or cloud provider network flow logs for the affected window. If you see outbound connections to that domain, you have confirmed exfil and need to treat this as a full breach.

The lockfile strategy that would have helped (and what doesn't)

Composer's content-hash verification covers the package contents after resolution. It does not verify that a tag in the upstream repository points at the commit you expect. That's the gap this attack exploited.

The mitigation that would have helped: using commit-pinning in your composer.json instead of version tags for high-value packages. This is verbose and most projects don't do it. But if you are running a solo SaaS where a credential breach would be catastrophic, it's worth doing for any package in your dependency graph that has write access to config or environment files.

Packagist has now introduced tag-signature verification as a beta feature for package publishers. It requires maintainers to GPG-sign their tags. Most packages don't use it yet. The ones that do are safer.

The honest take

The Laravel-Lang attack is not the last time this technique will be used. Tag-rewriting is subtle enough that it bypassed the standard defenses, hit a well-trusted ecosystem, and was in the wild for at least 48 hours before widespread disclosure. The npm postinstall attack from last week targeted JavaScript. This one targets PHP. The same group (identified as TeamPCP by Palo Alto's Unit 42) appears responsible for both.

If you're a solo operator running production Laravel code and you haven't audited your Composer installs in the last week: do that now, before you read another article about it.

Author

Lukas

@lukcombinator

Sources

• Laravel-Lang PHP Packages Compromised to Deliver Cross-Platform Credential Stealer
• Laravel-Lang Composer Tag-Rewrite Supply-Chain Attack (Mend)
• Supply Chain Attack Targets Laravel-Lang Packages with Credential Stealer (Aikido)
• The npm Threat Landscape: Attack Surface and Mitigations (Palo Alto Unit 42)