Laravel-Lang packages compromised

On May 22, 2026, attackers rewrote version tags across several Laravel-Lang packages, converting a widely used PHP localization dependency into a malware delivery channel. Security researchers at Aikido and StepSecurity said the attack affected `laravel-lang/lang`, `laravel-lang/http-statuses`, `laravel-lang/attributes` and, in StepSecurity’s analysis, `laravel-lang/actions`. The malicious code executed through Composer’s autoload mechanism, meaning it could run when an affected application loaded dependencies rather than after a developer manually invoked a script. The compromise stood out because researchers said the attacker did not need to publish one obviously bad release. Instead, the attacker repointed existing tags to malicious commits, so normal version constraints could still resolve to poisoned artifacts. StepSecurity said all 502 tags in `laravel-lang/lang` were rewritten between 22:32 UTC and 23:24 UTC on May 22, while Aikido said 233 versions across three repositories were compromised. The Hacker News, citing Socket, reported that more than 700 versions associated with the affected packages were identified across May 22 and May 23. (aikido.dev) ### How did a translation package become a malware vector? Aikido said the attacker inserted a file named `src/helpers.php` into affected tags and arranged for it to load automatically through Composer. The file appeared to define normal Laravel localization helper functions, but the malicious block beneath them fingerprinted the host and contacted an external command-and-control domain. StepSecurity likewise said the attacker modified `composer.json` and `src/helpers.php` in each malicious commit. (github.com) GitHub’s tag model was central to the attack. Aikido said the malicious code was never committed to the official repositories and that the attacker exploited GitHub’s ability to point version tags at commits from a fork of the same repository. That design let the poisoned tags inherit trusted package names while hiding the payload from a quick review of the main branch history. ### What did the payload try to steal? (aikido.dev) The command-and-control domain identified by researchers was `flipboxstudio.info`. Aikido said the dropper fetched a second-stage payload from that domain with SSL verification disabled, then launched it differently depending on the operating system: via a `.vbs` script and `cscript` on Windows, and via `exec` on Linux and macOS. StepSecurity said its isolated detonation showed the malware exfiltrating runner environment data and dropping temporary artifacts before deleting them. (aikido.dev) Socket, as quoted by The Hacker News, said the stealer targeted cloud metadata and credentials, Kubernetes service-account tokens, CI/CD secrets, developer-platform tokens, browser data and cryptocurrency wallet material. The reported targets included GitHub Actions, GitLab Runners, CircleCI, Jenkins, ArgoCD, DigitalOcean, Heroku, Vercel, Netlify, Railway, Fly.io and HashiCorp Vault, along with browser login data and wallet seed phrases. (aikido.dev) ### Which packages were affected, and how broad was the blast radius? The named packages in public reports were `laravel-lang/lang`, `laravel-lang/http-statuses`, `laravel-lang/attributes` and `laravel-lang/actions`. StepSecurity said there was “no safe version to pin to today” other than a pre-May 22 commit SHA that a user could independently verify, because every git tag in the affected repositories had been rewritten. Aikido’s public post focused on three repositories, while StepSecurity and GitHub issues filed by its team included four. (thehackernews.com) Packagist moved to limit further downloads. Aikido said it reported the attack to Packagist, which removed the malicious versions and temporarily unlisted the affected packages. A GitHub issue in `laravel-lang/lang` repeated that account and linked to the StepSecurity write-up for indicators of compromise and recovery guidance. ### What should developers check first? StepSecurity said fresh installs or `composer update` runs against the affected packages could pull the payload, and the GitHub issue urged users to inspect projects immediately. (stepsecurity.io) The first practical check is the project’s `composer.lock` and dependency history for any installation or update of the named Laravel-Lang packages on or after May 22, 2026, then compare resolved commits or package metadata against known-good pre-attack states from local clones or verified mirrors. That recommendation is an inference from the researchers’ findings and recovery notes, not a new vendor advisory. (aikido.dev) GitHub issues opened on May 22 and May 23 remain the main public coordination points, and the StepSecurity and Aikido writeups contain the current indicators, affected repositories and remediation details. Packagist had already taken down malicious versions by the time those issues were updated. (github.com) (stepsecurity.io)