Laravel-Lang Packages Under Attack: Supply Chain Attack Endangers Thousands of PHP Projects

In May 2026, a targeted supply chain attack shook the PHP developer community. Four popular Laravel-Lang packages were compromised — and within just six hours, credential-stealing malware landed in over 5,500 GitHub repositories worldwide. Anyone using Laravel localization packages should act now.

What is a supply chain attack?

In a supply chain attack, the actual target isn't attacked directly — instead, a trusted third party in the software supply chain is compromised. In this case, legitimate, widely used open-source packages were poisoned — with the goal of infecting as many developer systems as possible at once.

Particularly insidious: the attackers didn't push a single line of code into the official repositories directly. Instead, they exploited a little-known GitHub feature.

How did the attack work?

GitHub allows version tags to point to commits from forks of the same repository. The attackers created a malicious fork, injected malicious code there — and linked historical version tags of the official packages to these compromised commits.

The result: anyone who installed an already-known, supposedly stable version via Composer, or had it cached, automatically received the manipulated version. The PHP autoloader loaded the malware without any further action.

Which packages are affected?

Four packages from the laravel-lang namespace on Packagist were compromised:

• laravel-lang/lang

• laravel-lang/attributes

• laravel-lang/http-statuses

• laravel-lang/actions

A total of around 700 historical versions were manipulated — compromising over 5,500 downstream repositories in just six hours.

What was stolen?

The payload was a roughly 5,900-line PHP credential stealer with 15 specialized modules. The malware's targets:

• Cloud credentials (AWS, Azure, GCP)

• Database credentials and API keys

• Passwords stored in browsers

• Crypto wallet data

• Developer secrets from local .env files

The community's response

Packagist reacted quickly: the malicious versions were removed and the affected packages were temporarily delisted. The official packages are available again in the meantime — in cleaned-up versions. Security researchers from Aikido and Snyk documented the attack in detail and helped understand its scope.

What should you do now?

If you use one of the affected packages in your projects, act immediately:

• Check installed versions: composer show laravel-lang/*

• Rotate all secrets immediately: database passwords, API keys, cloud credentials

• Run a security audit of the affected environments

• Update to the latest cleaned-up versions

Conclusion

This attack shows impressively how vulnerable modern software ecosystems are due to their dependence on third-party packages. Version pinning alone doesn't protect you — if tags are manipulated, that's not enough. Regular dependency audits, automated security scans, and fast responses to security advisories are no longer optional today, but mandatory for every developer.