Several Laravel-Lang Composer packages were compromised after attackers rewrote release tags to run a PHP credential stealer through Composer autoload. StepSecurity says the tag rewrite happened on May 22, 2026, and affected packages such as laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/actions, and laravel-lang/attributes [1].
The dangerous part is the trigger. The attacker added src/helpers.php into autoload.files, so the malicious PHP runs when a project loads Composer’s generated autoloader. Socket counted more than 700 affected versions and described the timing as a mass rewrite pattern, not a normal single-version package compromise [2].
flipboxstudio.info, the attacker-controlled domain used by the payload. Source: StepSecurity.Why this Composer attack is serious
This is not a case where an application has to call a vulnerable function. In a normal PHP project, vendor/autoload.php is loaded early and often: during tests, framework bootstrapping, queue workers, deployment scripts, and CI jobs. That means a compromised package can run before a developer notices anything unusual in the application itself.
StepSecurity’s detonation of laravel-lang/http-statuses showed the payload reaching flipboxstudio.info, dropping files under /tmp, attempting to collect runner environment data, and deleting artifacts within seconds. The most sensitive exposure is CI/CD context: GitHub tokens, environment files, cloud credentials, deployment secrets, and anything readable from the runner process environment.
Who should treat this as exposed?
Assume exposure if a CI runner, deployment host, or developer machine installed or updated the affected Laravel-Lang packages after the tag rewrite window. The safest signal is not “the app still works.” The safer signal is whether composer.lock, Composer cache, runner logs, and outbound network telemetry show one of the rewritten versions or a connection to the attacker domain.
- Check
composer.lockfor unexpected Laravel-Lang package versions or timestamps. - Search CI logs for Composer installs or updates touching
laravel-lang/*. - Hunt DNS, proxy, EDR, and firewall logs for
flipboxstudio.info. - Rotate tokens available to affected runners, including GitHub, npm/Packagist, cloud, registry, and deployment secrets.
- Rebuild runners or developer environments if the package ran in a privileged or long-lived context.
What makes this different from a normal package typo
The tag rewrite pattern matters. Instead of publishing one obviously new malicious release, the attacker changed historical tags across multiple packages. That can catch teams that pin semver ranges but still allow Composer to resolve or refresh metadata during builds. It also makes “we did not intentionally upgrade” a weak defense if the pipeline performed a fresh install.
For defenders, this is a Composer autoload problem before it is a Laravel problem. If CI or a developer machine ran composer update against the affected packages after the tag rewrite window, treat that environment as exposed. Aikido also described a larger PHP stealer that collects credentials and removes traces from disk [3].
The immediate triage is to inspect composer.lock, block or hunt for flipboxstudio.info, and rotate secrets reachable from the runner or developer shell. This differs from npm worm cases because no application method needs to be called; the autoloader itself becomes the execution path. For comparison, we covered the npm-side pattern in Mini Shai-Hulud’s TanStack compromise and the later Grafana missed-token incident.
Related: the Megalodon GitHub Actions malware campaign is another example of CI secrets becoming the real target after a repository is poisoned.
References
- StepSecurity, “Laravel-Lang Supply Chain Attack,” May 22, 2026. Report
- Socket, “Laravel Lang Compromised with RCE Backdoor Across 700+ Versions,” May 23, 2026. Analysis
- Aikido, “Supply chain attack targets Laravel-Lang packages with credential stealer,” May 23, 2026. Analysis
Related supply-chain context: A later Packagist postinstall malware campaign shows why PHP projects also need to inspect package.json and CI install logs, not only Composer metadata.
Related supply-chain context: Нова кампанія Packagist postinstall malware показує, чому PHP-проєктам варто перевіряти не лише Composer metadata, а й package.json та CI-логи.
