On May 22 and May 23, 2026, an attacker republished hundreds of malicious versions under historical release tags for four community-maintained Laravel localization libraries that are published on Packagist under the laravel-lang namespace.
The poisoned releases did not originate from the official source repositories. Instead, the attacker pointed Git tags to commits in an attacker-controlled fork, exploiting how Packagist resolves tags from GitHub. Additionally, an injected helpers.php file was wired into Composer’s autoload.files entry, causing it to run on every PHP request the moment the package is installed. That hook reaches out to flipboxstudio[.]info , downloads a cross-platform second stage, and runs a credential stealer that scrapes cloud keys, Kubernetes and Vault secrets, CI/CD tokens, SSH material, environment files, browser data, password manager vaults, crypto wallets, and messaging tokens.
Every environment that pulled one of the affected Laravel localization library versions should be treated as compromised until proven otherwise.
The packages in scope live under the laravel-lang/* namespace on Packagist and GitHub.
They are widely adopted by the Laravel community for shipping translation strings, validation messages, HTTP status descriptions, and similar localized assets across more than seventy languages.
The Laravel core team does not maintain them, and they are not part of the official Laravel framework, even though they are installed in the typical Laravel application directory and often appear as transitive dependencies in other localization helpers. Because the packages are pulled in through Composer and registered via composer.json , any malicious code that ships with them is loaded and executed automatically by the application’s runtime.
All published versions of the following four packages are currently treated as compromised. Packagist has unlisted the packages while remediation is in progress.
Bundled translation strings for Laravel applications.
laravel-lang/http-statuses
Localized HTTP status code messages.
laravel-lang/attributes
Translation strings for model and form attribute names.
Localized strings for action and verb-style messages.
Earlier counts by researchers put the number of poisoned versions at roughly 233, but the figure climbed as the attacker continued pushing tags. Current reporting shows approximately 700 historical versions across the four packages.
First wave of malicious tags appears across the laravel-lang organization. An early snapshot catalogs roughly 233 poisoned versions across the four packages.
Republication of historical tags continues in bursts, with multiple repositories receiving rewrites within seconds of each other. Total count climbs past 700 versions.
Packagist removes the malicious releases and temporarily unlists the four packages. Public reporting and IoCs are shared by the wider research community.
Snyk continues to monitor the incident; investigation by the Laravel-Lang maintainers, Packagist, and external researchers is still in progress.
The attacker did not push any commits to the official laravel-lang source repositories. Instead, they leveraged a quirk of the GitHub-to-Packagist publishing flow: a Git tag created within an organization can resolve to a commit in a fork outside that organization. Packagist then ingested those tags and treated the fork commits as genuine releases of the official package.
Once a malicious tag was in place, any new Composer install that resolved one of the affected versions pulled down the fork’s code. The payload was hidden in a newly added file, src/helpers.php , and registered in composer.json under autoload.files . Composer’s autoloader unconditionally requires every file in that list, so the malicious code runs at the very start of the PHP request lifecycle, including during commands, background workers, and queue handlers.
The first stage embedded in src/helpers.php is intentionally light. It writes an infection marker to a per-host temporary directory so the host is only infected once, then fetches a second stage from and executes it in the background. The launcher logic is platform-aware and works on Linux, macOS, and Windows.
The second stage is a credential and secrets stealer. Once it lands, it walks through a long list of sources looking for anything of value:
Cloud provider credentials and tokens (for example, AWS, GCP, and Azure profile files).
Kubernetes kubeconfig files, HashiCorp Vault tokens, and CI/CD secrets are present in the environment.
SSH private keys and known _ hosts data.
Application .env files containing database, API, and service credentials.
Browser data, including cookies, history, and stored logins.
Password manager vaults that are accessible on disk.
Cryptocurrency wallet files and keystores.
Messaging and collaboration tokens for tools such as Slack, Discord, and Telegram.
Collected data is encrypted and shipped out to . After exfiltration, the stealer attempts to delete its dropped files to slow down forensic recovery. On Windows hosts, the chain involves a .vbs launcher script and an executable artifact named DebugChromium.exe that has been observed on infected systems.
Use the following indicators to hunt for affected systems. The C2 domain and URLs should be treated as malicious.
Command and control domain
flipboxstudio [ . ] info
Second-stage payload URL
Exfiltration endpoint
Malicious source file
src/helpers.php (registered via composer.json autoload.files)
Infection marker file
/.laravel _ locale/
Dropped stealer (any OS)
/.laravel _ locale/ .php
Windows launcher script
/.laravel _ locale/ .vbs
Suspicious runtime behavior
Outbound network requests to flipboxstudio [ . ] info; reads from /var/run/secrets/ and /proc/ [ pid ] /environ; background php or cscript process execution.
Treat any host that resolved one of the four packages between May 22 and May 23, 2026, as a suspect, even if it has since been rebuilt. The fastest signal is at the dependency level: examine composer.lock and composer.json across your projects for any references to the laravel-lang packages listed above. A few practical checks follow.
build and deployment artifacts for laravel-lang/lang , laravel-lang/http-statuses , laravel-lang/attributes , or laravel-lang/actions and capture the version and integrity hash recorded in composer.lock.
Inspect any installed copy under vendor/laravel-lang/*/ for the presence of src/helpers.php and check whether composer.json declares it under the autoload files key. A legitimate localization package has no reason to ship a helpers file that auto-loads on every request.
On Linux and macOS hosts, look in $TMPDIR and /tmp for a .laravel_locale directory—any content there indicates execution. Capture them before cleanup for forensic analysis.
On Windows hosts, the user temp directory (typically %TEMP% ) for a .laravel_locale folder containing . vbs droppers whose filenames are eight random hex characters. Separately, scan the filesystem for any executable named DebugChromium.exe .
Check egress proxy, DNS, and firewall logs for any lookups or connections to flipboxstudio[.]info . Block the domain at the resolver and at the perimeter.
In EDR and endpoint logs, hunt for unexpected background PHP or CScript process executions. On Linux and macOS, additionally watch for reads from /var/run/secrets/ and ` /proc/ [ pid ] /environ ` , which the credential stealer accesses while harvesting secrets.
For Snyk users, the Open Source product and the Snyk Vulnerability Database already flag the affected versions. Run an immediate scan against any Composer-based repositories and pay close attention to monorepos and shared platform code.
The Snyk CLI will automatically detect your Composer lockfile and detect vulnerable and malicious packages:
The Snyk CLI is free. If you don’t yet have the Snyk CLI installed, follow the Snyk CLI user docs .
If you connect Snyk to your git repositories, Snyk can automatically open PRs to update vulnerable packages in your composer.lock file to secure versions.
For Snyk Enterprise customers, we have already rerun scans on your behalf, and you can check Analytics > Remediation > Zero Day Report to see if you’re impacted.
Where the affected packages are confirmed to have been installed, assume that anything readable by the PHP process at execution time has been exfiltrated, and act accordingly. The order below reflects the typical incident response sequence.
Quarantine impacted hosts. Pull any internet-facing services that ran the affected versions out of rotation, take disk snapshots for forensics, and rebuild from a known-clean image rather than cleaning in place.
Make sure you do not pull the affected Laravel Lang set of packages (and likely other packages from this maintainer/team). Because the attacker rewrote historical Git tags, no published version number can be trusted on its own; an older release number may now resolve to the malicious fork.
Rotate every credential the PHP process could have read. That includes cloud provider keys, database passwords, queue and cache credentials, third-party API tokens, OAuth client secrets, SSH keys, signing keys, Vault and Kubernetes tokens, and any secrets injected by CI/CD.
Audit human accounts that the same workstations. Browser stored logins, password manager vaults, crypto wallets, and Slack or Discord tokens may also have been stolen. Rotate browser-stored passwords, invalidate sessions, and review MFA enrollments.
Block the C2 domain. Add flipboxstudio [ . ] info to DNS sinkholes, proxy denylists, and EDR detections. Even a single attempt at resolution is a strong signal of exposure.
Review SCM and registry permissions, as laravel-lang/* could have been pulled transitively. Confirm that your own GitHub, GitLab, and Packagist organizations have hardware-backed MFA, scoped tokens, and a review step for tag creation and package publication.
This incident is a useful reminder that a package's trust boundary is not the source repository in your browser tab. It is the chain of systems that decides which commit becomes a published artifact. A few practices reduce the blast radius of similar attacks:
Verify integrity at install. Composer records package content hashes in composer.lock; use - -no-cache and integrity verification in CI to make tampering visible.
Adopt egress controls in build environments. CI runners and production containers should not be able to reach arbitrary domains. An allowlist would have prevented the second-stage download in this case.
Use short-lived, scoped secrets. Long-lived credentials in .env files magnify the damage from any in-process secret theft.
We also recommend reviewing your security practices and learning how to secure the Laravel PHP framework from a prior article we published, as well as the Snyk Learn resource for secure PHP development practices .
Snyk products and infrastructure are not affected by this incident. Snyk advisories for the impacted packages have been published, and the Snyk Vulnerability Database is being updated as new version ranges are confirmed. Snyk continues to monitor the situation and will revise this advisory as additional details emerge.
The full story
This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.
