Laravel-Lang Package Attack Compromises 700 Versions and Installs Credential Stealer in PHP Environments

502 Tags Rewritten in Under an Hour

In the early hours of 22 May 2026, between 22:32 and 23:24 UTC, an agent with write access to the Laravel-Lang organisation on GitHub rewrote the 502 historical tags of four community-maintained PHP packages: laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes, and laravel-lang/actions. The incident was publicly disclosed by firms Socket and Aikido Security on 23 May, with an issue opened in the official project repository confirming the compromise on the same date.

These packages are not part of the official Laravel framework. They are third-party localisation libraries widely used by Laravel applications for internationalisation, distributed via Packagist, the central repository for PHP packages. Socket recorded over 700 compromised versions; Aikido confirmed 233 affected package artifacts across three of the four repositories. The figures vary because Socket includes all rewritten historical tags, while Aikido only counts artefacts with verified functional payloads.

How the Payload Executes Without Alerts

The malicious file src/helpers.php was added to each compromised version and registered under the autoload.files key in composer.json. Any developer who executed composer install or composer update against a compromised version would automatically load the stealer on the first PHP request of the application, without any security warning or visible hash change on Packagist. The code connects to the C2 domain flipboxstudio[.]info to download a cross-platform second stage, compatible with Windows, Linux, and macOS.

Cloud keys (AWS, GCP, and Azure), Kubernetes and HashiCorp Vault secrets, CI/CD pipeline tokens, SSH keys, .env files, Chromium and Firefox browser data, password manager vaults, and local configurations for tools like Anthropic Claude Code feature among the target data of the stealer. For DevSecOps teams with multiple repositories, a single composer update on a build machine could have exposed the entire chain of organisational credentials in a matter of seconds.

The metadata of the compromised commits lists the author as "Your Name <you@example.com>", the default Git configuration, which suggests the use of a newly configured environment or a deliberate attempt to leave no identifiable traces.

The Vector That Distinguishes This Attack

The attacker did not exploit any vulnerability in Packagist or Composer. They obtained direct write access to the Laravel-Lang organisation on GitHub and replaced historical versions that developers consider stable and audited. Unlike classic typosquatting or the publication of new malicious versions, this attack compromised older versions locked in composer.lock files without altering any visible version number to the development team. Continuous integration pipelines configured to pin historically verified versions—specifically to avoid unaudited updates—became the primary vector for distributing the payload.

StepSecurity, which tracks the Megalodon campaign of GitHub Actions pipeline compromises active since 18 May 2026, connected this incident to a broader pattern: the attacker obtains organisational credentials from GitHub and operates at scale against all accessible repositories. The initial access vector to the Laravel-Lang organisation has not yet been publicly confirmed by security firms.

Immediate Actions for Security Teams

Organisations dependent on the four affected packages should audit their Composer dependency graph and compare the hashes of installed versions against legitimate records from Packagist. The GitHub Advisory Database published a detection command to check the system logs for any exploitation. Any credentials present in environments that ran the compromised versions from 22 May should be treated as potentially exposed and rotated: at a minimum, GitHub Actions tokens, cloud access keys, and SSH certificates.

Packagist and the Laravel-Lang team have removed the malicious versions and restored the repositories from the legitimate history. The incident points to a persistent structural gap in PHP dependency chains: Composer relies, by default, on the integrity of the underlying Git commits tied to the tags without independent cryptographic verification. Projects with SLSA level 3 or signatures via Sigstore would automatically detect the tampering; most PHP workflows still do not operate at this level of traceability, and the arrival of the attack via a trusted GitHub organisation should change the calculus for security teams that have so far delayed adoption.