A compromise in the community-maintained Laravel Lang project appears to have pushed remote-code-execution backdoors into multiple packages, including historical versions of laravel-lang/http-statuses. Socket says the activity spans hundreds of releases and may affect more than 700 versions.
The important boundary: these packages are not part of the official Laravel framework. They are third-party localization packages used by Laravel applications. That does not make the incident small. It changes where teams should look.
If a compromised package version was installed, the malicious code may have run automatically through Composer’s autoloader during normal PHP application execution. That puts application servers, developer machines, CI runners, and cloud credentials in scope.
What Socket says happened#
Socket’s report describes coordinated tag activity across repositories in the Laravel Lang GitHub organization. Newly published tags appeared in rapid sequence on May 22 and May 23, 2026, with many created only seconds apart.
The pattern was seen across version lines including 12.x, 13.x, 14.x, and 15.x, and across multiple Laravel Lang repositories. Socket specifically calls out Laravel-Lang/http-statuses and analysis of composer/laravel-lang/lang@14.3.7.
That timing matters. A single malicious version can be explained by one bad publish, one stolen token, or one maintainer mistake. Rapid publication of many historical tags across several repositories points to something broader: access to organization-level credentials, repository automation, or release infrastructure. Socket does not present that as a final attribution, but the release pattern is not normal package maintenance.
Aikido Security also surfaced the compromise publicly, helping alert the Laravel and PHP communities. At the time of Socket’s post, the investigation was still developing.
Why Composer autoload makes this worse#
The reported backdoor is tied to a PHP file registered in Composer configuration for automatic loading. In Composer packages, files listed under the autoload configuration can run when the Composer autoloader runs.
That is the dangerous part. A developer does not need to manually call a suspicious function. An application does not need to route traffic to a specific endpoint. If the package is installed and the autoloader is used, the malicious code can execute during ordinary runtime.
Socket says the malware builds its command-and-control hostname dynamically at runtime using character codes, a basic evasion step against static string scanning. It then reaches out to https://flipboxstudio[.]info/payload, disables TLS certificate verification, and uses a fake Mozilla User-Agent to make retrieval more likely.
The downloaded payload is written to a hidden temporary path under sys_get_temp_dir()/.laravel_locale/. Execution differs by platform. Socket describes background execution on Unix-like systems and a Windows-compatible path as well, making the second-stage behavior relevant across Linux, macOS, and Windows environments.
The loader also creates a per-host marker using an MD5 hash derived from local system characteristics. That appears designed to make the payload trigger once per machine. One-time execution reduces noise and can make incident response harder, because the absence of repeated activity does not prove the machine was clean.
The second-stage payload targets secrets, not just servers#
Socket characterizes the second-stage payload as a cross-platform PHP information stealer. The described behavior is broader than a simple webshell.
The payload initializes multiple collectors aimed at credentials and operational secrets. According to Socket, it scans files, databases, and environment variables using large regular-expression dictionaries for secrets such as AWS keys, GitHub tokens, Stripe keys, Slack and Discord tokens, JWTs, and private keys.
The cloud and CI/CD targeting is the real blast-radius concern. Socket reports collectors for cloud metadata endpoints, including EC2 instance metadata, as well as local configuration for Azure, Google Cloud, DigitalOcean, Heroku, Netlify, and Vercel. It also targets Kubernetes service account tokens, Helm registry configuration, Vault tokens, and CI systems including Jenkins, GitLab Runners, GitHub Actions, CircleCI, TravisCI, and ArgoCD.
That maps directly to modern deployment chains. A compromised localization package on a developer laptop can become stolen GitHub access. A compromised build runner can become cloud access. A compromised application server can become IAM role theft.
Socket also says the payload looks for wallet data and browser extension storage associated with crypto wallets such as MetaMask, Phantom, and Trust Wallet. That does not mean every affected host had those assets. It does show the stealer was written to harvest whatever sensitive material it could find, not only Laravel-specific data.
What teams should check now#
Start by treating this as a dependency and credential-exposure incident, not as a Laravel framework vulnerability.
Check whether your projects use Laravel Lang packages from the affected organization, especially laravel-lang/http-statuses and laravel-lang/lang. Review composer.lock, not just composer.json, because the lockfile records what was actually installed.
Practical checks:
- Inspect recent Composer installs and updates around May 22–23, 2026 UTC.
- Review installed package versions against advisories from Socket, Aikido, Laravel Lang maintainers, and Packagist metadata as updates arrive.
- Search hosts for the temporary path pattern
.laravel_localeunder the system temp directory. - Look for outbound traffic or DNS activity involving
flipboxstudio[.]info. - Rotate secrets that may have been exposed from affected developer machines, CI runners, build servers, and application hosts.
- Pay special attention to GitHub, GitLab, cloud IAM, CI/CD, Vault, Kubernetes, deployment, and payment provider credentials.
Do not limit the response to production servers. Composer packages are often installed first on developer workstations and CI runners. Those environments usually hold the most useful tokens.
If you find evidence of execution, assume local environment variables and readable configuration files may have been exposed. Secret rotation should be paired with log review: cloud audit logs, Git provider token use, CI job history, package publishing activity, and unusual deployments.
What not to overclaim#
The source material supports a serious supply-chain compromise affecting Laravel Lang packages. It does not support calling the official Laravel framework compromised.
It also does not prove that every historical tag was installed by users, that every installation successfully executed the second stage, or that every affected machine lost secrets. Those are investigation questions.
The safest working assumption is narrower and still severe: if a compromised version was installed and Composer’s autoloader ran, the host should be treated as potentially exposed. That is enough to justify dependency review, host inspection, and credential rotation for systems that touched the affected packages.
The lesson is not new, but this case makes it concrete. A small third-party package can sit close enough to application startup that its compromise becomes code execution. In PHP ecosystems built around Composer autoloading, release integrity is runtime integrity.