Laravel Lang Packages Hijacked: Credential Malware

Laravel Lang Supply Chain Attack Exposed 700+ Package Versions

A supply chain attack targeting Laravel Lang localization packages has put thousands of PHP developers at risk. Attackers rewrote Git tags across four Composer repositories to point at malicious commits, deploying a cross-platform credential stealer without ever modifying the original source code. This is a precise, targeted campaign, and if your project pulled any affected version of these packages between roughly 22:32 UTC and 00:00 UTC on the attack date, you may have already executed malicious code.

The affected packages are laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes, and possibly laravel-lang/actions. These are third-party localization utilities, not part of the official Laravel framework. Security firms StepSecurity, Aikido Security, and Socket each independently confirmed the compromise. Aikido counted 233 poisoned versions across three repositories. Socket puts the total closer to 700 historical versions.

How the Git Tag Rewrite Attack Worked

Most supply chain attacks inject code into a new package version. This one was different. The attacker did not publish a new malicious release. Instead, they rewrote every existing Git tag in each repository to point at a new malicious commit hosted in an attacker-controlled fork. Because Composer resolves packages by Git tag references, not by content hash, pulling any of those versions fetched the malicious commit instead of the legitimate one.

All four repositories shared the same fake author identity, the same modified files, and the same payload behavior. That consistency suggests a single actor with org-wide push access to the Laravel Lang GitHub organization, likely via one compromised credential.

The malicious changes introduced a file called src/helpers.php, registered in the autoload section of composer.json. Composer loads autoloaded files automatically on boot, so no explicit call was needed. The file acted as a dropper, reaching out to flipboxstudio[.]info to download a second-stage PHP payload.

What the Credential Stealer Actually Does

The downloaded PHP payload is a large, cross-platform infostealer targeting Linux, macOS, and Windows. It harvests cloud credentials, Kubernetes secrets, Vault tokens, Git credentials, CI/CD secrets, SSH keys, browser data, cryptocurrency wallets, password manager data, VPN configurations, and local .env files.

Regex patterns inside the payload specifically target AWS access keys, GitHub tokens, Slack tokens, Stripe secrets, database connection strings, JWTs, SSH private keys, and crypto recovery phrases, scanning both files and environment variables.

On Windows, the payload also decodes and drops a base64-embedded executable into %TEMP% under a random .exe filename. BleepingComputer identified this binary as DebugElevator, an infostealer targeting Chrome, Brave, and Edge. It extracts App-Bound Encryption keys to decrypt stored browser credentials. An embedded PDB path references a user named Mero and the string claude, which may indicate AI-assisted development of the Windows component.

Once collected, the stolen data is encrypted and sent back to the C2 server.

Steps Developers Should Take Right Now

Packagist removed the malicious versions and temporarily unlisted the affected packages after Aikido reported the incident. That limits new exposure, but it does not help anyone who already installed a poisoned version.

If your project uses any of the four affected packages, take these steps immediately:

• Audit your Composer lock file. Check which exact version hashes were installed and compare against known-good commits.
• Rotate every credential your build environment can access. That includes AWS keys, GitHub tokens, database passwords, .env secrets, and SSH keys.
• Check outbound network logs for connections to flipboxstudio[.]info. Any hit on that domain confirms execution of the malicious payload.
• Scan affected systems for the dropped .exe in %TEMP% on Windows.
• Run a full automated vulnerability scan on your application to identify any lingering exposure or unexpected behavior introduced through the compromised dependency.

For ongoing supply chain risk, consider pinning dependencies by commit hash rather than relying on mutable version tags, and integrate integrity verification into your CI pipeline.

Does Composer cache protect me if I installed these packages before the attack? No. Composer's local cache stores the resolved code. If you pulled a poisoned tag before Packagist removed the versions, your cache contains the malicious helpers.php file. Clear your cache, reinstall from scratch, and verify hashes manually.

How do I know which version I installed was affected? Check your composer.lock file for the exact commit hash resolved for each package. Compare that hash against the known-good commits in the official Laravel Lang repositories. Any hash that does not match a legitimate commit is suspect.

Can a DAST scanner detect this kind of supply chain compromise? A DAST scanner won't catch the malicious file before it runs, but it can detect abnormal outbound connections, unexpected application behavior, and exposed secrets in HTTP responses caused by the malware. Use it alongside dependency auditing, not instead of it. You can start a free scan at VibeWShield to check your running application for indicators of compromise.

Run a free security scan on your Laravel application at VibeWShield