Laravel-Lang Packages Hijacked: 700 GitHub Repos Compromised to Steal Your AWS Keys and Browser Passwords

Another Day, Another Supply Chain Attack

On May 22, 2026, security researchers at Aikido detected an active supply chain attack targeting Laravel-Lang — one of the most popular internationalization packages in the PHP ecosystem. Attackers had compromised over 233 versions across multiple Composer packages by hijacking approximately 700 GitHub repositories, delivering a sophisticated cross-platform credential stealer to any developer who installed or updated the affected packages.

If you’re a Laravel developer who ran composer update recently, you may have just handed your AWS keys, cloud credentials, and browser passwords to an unknown threat actor.

Which Packages Were Compromised

The attack targeted the laravel-lang organization’s core packages:

laravel-lang/lang — the primary language pack used by hundreds of thousands of Laravel applications. laravel-lang/http-statuses — HTTP status code translations. laravel-lang/attributes — form attribute translations. laravel-lang/actions — action name translations.

These aren’t obscure libraries. Laravel-Lang is the de facto standard for internationalization in the Laravel ecosystem. Any multi-language Laravel application likely depends on at least one of these packages. The collective download count runs into millions.

More than 700 versions associated with these packages were identified as compromised, indicating automated mass tagging. The attacker didn’t just poison one version — they retroactively compromised every version tag they could access.

How the Attack Exploited Composer’s Tag System

This attack leveraged a subtle but devastating property of how GitHub and Composer interact. GitHub allows version tags to point to commits from a fork of the same repository. The attacker exploited this by creating a malicious fork, adding credential-stealing code, and then creating tags in the original repository that pointed to commits in their malicious fork.

When Composer resolves package versions, it follows these tags. So even though the original repository’s main branch was clean, the version tags that Composer downloads pointed to the attacker’s malicious code. It’s a supply chain attack that doesn’t require compromising the maintainer’s account or the repository’s default branch.

This vulnerability in the tag system means any GitHub-hosted Composer package is potentially vulnerable to this technique. The attack surface extends far beyond Laravel-Lang.

The 5,900-Line Credential Stealer

The malware is no amateur script — it’s a 5,900-line PHP credential stealer organized into fifteen specialist collector modules. It loads automatically via Composer’s autoloader feature, meaning it executes the moment a developer’s application boots — no user interaction required.

The payload architecture shows professional development practices: modular design, error handling, multiple exfiltration channels, and cross-platform compatibility. Someone invested significant engineering effort into building this malware, suggesting either a well-resourced criminal group or a state-sponsored operation.

The stealer’s modular design means each collector module operates independently. If one fails (perhaps because a particular credential store isn’t present), the others continue harvesting. This resilience makes the malware effective across diverse development environments.

What the Malware Targets

The fifteen collector modules target an astonishing range of credentials and secrets:

AWS access keys, secret keys, and session tokens — granting full access to victims’ cloud infrastructure. GCP service account credentials and Azure tokens — covering all three major cloud platforms. Every .env file on the system — which in Laravel applications typically contain database passwords, API keys, mail credentials, and application secrets. All config files in standard locations. Saved passwords from 17 Chromium-based browsers including Chrome, Edge, Brave, and Opera.

The browser password theft is particularly alarming. Developers who store passwords in their browser — including credentials for production servers, admin panels, and other critical infrastructure — would have everything exposed. Combined with the cloud credentials, an attacker could potentially access and control entire production environments.

Exfiltration Method

After collecting everything it can find, the stealer encrypts the harvested data with AES-256 and sends it to flipboxstudio[.]info/exfil. The encryption ensures that even if network monitoring captures the outbound traffic, the contents aren’t readable without the decryption key.

The use of AES-256 encryption for exfiltration is a sophistication marker — it prevents security tools that inspect outbound traffic content from flagging the data transfer as suspicious. The traffic appears as normal encrypted HTTPS communication to an apparently legitimate domain.

How Many Developers Are Affected

The exact number of affected developers is unknown, but the potential blast radius is enormous. Laravel is one of the most popular PHP frameworks in the world, and Laravel-Lang is the standard internationalization solution. Any developer who:

Ran composer update during the attack window. Installed a new Laravel project with internationalization packages. Had CI/CD pipelines that automatically pull latest package versions. Used any of the four affected packages in any version.

…could be compromised. The 233 compromised versions span the packages’ entire version history, meaning even developers pinning to specific older versions may have received malicious code.

Packagist’s Response

Packagist — the Composer package registry — took down the malicious versions and temporarily unlisted the affected packages to prevent further installations. The Laravel-Lang maintainers have published clean versions and are working to identify the full scope of the compromise.

However, the response highlights a gap in PHP’s supply chain security infrastructure. Unlike npm (which has automated malware scanning) or PyPI (which has started implementing trusted publishers), Packagist has limited automated defenses against this type of tag manipulation attack.

The incident has renewed calls for Composer to implement tag signing, trusted publishers, and automated malware scanning — features that other package ecosystems have already adopted or are actively developing.

How to Check If You’re Compromised

If you use any Laravel-Lang packages, take these steps immediately:

Check your composer.lock file for any of the four affected packages. If present, check the version and installation date against the attack window (May 22 onwards). Run composer audit if available in your Composer version. Search your project for any autoloaded files that don’t belong to known packages. Monitor outbound network connections for traffic to flipboxstudio[.]info.

If you find evidence of compromise: rotate ALL credentials immediately — AWS keys, database passwords, API tokens, everything in your .env files. Check your cloud provider’s access logs for unauthorized activity. Change all browser-saved passwords. Consider your entire development machine compromised and audit it thoroughly.

Conclusion

The Laravel-Lang attack demonstrates that even the most trusted packages in an ecosystem can be weaponized through creative exploitation of infrastructure features. The tag manipulation technique doesn’t require compromising maintainer accounts — it exploits a fundamental design decision in how Git tags and package registries interact.

For PHP developers, this is a wake-up call. The npm ecosystem learned these lessons years ago (remember event-stream?). The Composer ecosystem is now going through the same painful education. Lock your dependencies, verify your packages, and treat every composer update as a potential attack vector — because in 2026, it is.