On May 22 and May 23, 2026, attackers published hundreds of malicious versions across four community-maintained PHP libraries in the laravel-lang namespace: laravel-lang/lang, laravel-lang/attributes, laravel-lang/http-statuses, and laravel-lang/actions. These packages are localisation utilities used widely across Laravel applications. The attack did not introduce new version numbers. Instead, the attacker rewrote existing historical Git tags to point at commits in an attacker-controlled fork, exploiting how Packagist resolves version data from GitHub.

The mechanism is subtle and effective. Packagist caches package metadata from GitHub tags. When a tag is silently rewritten to reference a different commit, any application that resolves a version it has not yet cached receives the malicious code instead of the original. This means applications that had previously installed a clean version and were running from cached vendor directories were not immediately affected, but any new install, CI pipeline refresh, or composer update during the window of compromise would pull the backdoored code.

The injected payload is a helpers.php file wired into Composer’s autoload.files mechanism, causing it to execute on every PHP request automatically. The file fetches a ~5,900 line credential-stealing framework organised into fifteen specialist collection modules. The stealer targets cloud provider keys from AWS, GCP, and Azure credential files, Kubernetes and Vault secrets, CI/CD tokens from GitHub Actions, GitLab, and CircleCI, SSH private keys, .env files, browser saved credentials, password manager exports, cryptocurrency wallets, and messaging application tokens. Collected data is encrypted with AES-256 and exfiltrated to an attacker-controlled domain.

The scale is unusual even by supply chain attack standards. More than 700 versions across the four packages were associated with the compromise, suggesting the tag rewriting was automated rather than done manually. Security researchers at Aikido and StepSecurity confirmed the malicious commits and the exfiltration endpoint within hours of the attack being identified. Packagist and the legitimate package maintainers moved quickly to remediate.

What this attack has in common with the TanStack and Grafana Labs incident from the previous week is the exploitation of trust in a broadly-used open-source dependency to gain access to the environment of every organisation that installs it. The Laravel ecosystem is large. Organisations running Laravel in production, particularly those with CI/CD pipelines that perform clean installs on every build, would have had the credential stealer execute against their build environment and, depending on their pipeline configuration, potentially against their production servers.

Any organisation running Laravel applications should audit their Composer lock files for the affected packages, check whether their builds ran during May 22 or 23, review their CI/CD logs for outbound connections to unfamiliar domains, and rotate any secrets that could have been present in the affected environment. The vendor directory state at the time of the attack determines exposure, not the current state after remediation.

PHP supply chain security tooling is less mature than its Node.js counterpart. Composer has no native equivalent of npm audit’s integration with vulnerability databases at the same depth, and Git tag immutability is not enforced by Packagist by default. Teams working with PHP at scale should evaluate whether their pipelines verify package integrity beyond version pinning in composer.lock.

If your engineering team runs Laravel or other PHP frameworks and you want an audit of your dependency security posture, CI/CD secret handling, and pipeline integrity controls, contact Excello Digital. We help development teams identify and close the gaps that supply chain attacks exploit.