Laravel Lang Supply Chain Advisory

Laravel-Lang Supply Chain Attack: 700+ Historical Packagist Versions Compromised

Update - May 25, 2026: We have updated this post to reflect newer findings from the ongoing investigation. The update clarifies the compromise mechanism, replaces earlier references to a fork-based publishing flow, and adds guidance for Composer/Packagist users on how to determine whether a project was affected. Because the affected version numbers were later remapped to legitimate code, version numbers alone may not be enough to confirm impact. Snyk customers should review the “Detecting the Laravel Lang Supply Chain Attack with Snyk” section for updated scanning, triage, and remediation guidance.

TL;DR

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.

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 versions of the Laravel localization library should be treated as compromised until proven otherwise.

About the affected component

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.

Impacted packages

All published versions of the following four packages were treated as compromised. Packagist temporarily unlisted the packages, but they are now relisted following remediation.

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.

Known timeline

How the compromise happened

The attacker gained access to the compromised repositories via a leaked GitHub Personal Access Token (PAT), presumed to have resulted from a recent GitHub data breach. Using this access, the attacker replaced many or all release tags in four laravel-lang/ repositories with malicious lookalikes that point to their own commits which contained malware. The remaining legitimate repositories, including all previous commits, remained in place throughout the compromise.

Once a malicious tag was in place, any new Composer install that resolved one of the affected versions pulled down the lookalike commit'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.

Payload behavior

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 https://flipboxstudio\[.\]info/payload 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 https://flipboxstudio\[.\]info/exfil. 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.

Indicators of compromise

Use the following indicators to hunt for affected systems. The C2 domain and URLs should be treated as malicious.

Detection and ccanning guidance

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.

• Search 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, search 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.

Clarification of ignore guidance

Due to the nature of the compromise and subsequent remediation, Snyk systems may currently only recognize the latest version installed. Customers should perform a historical scan to confirm if the malicious package was ever installed between May 22 and May 23, 2026, and not rely solely on the latest version status. Assume any host that installed one of the four packages during the compromise window is affected until proven otherwise.

Detecting the Laravel Lang supply chain attack with Snyk

For Snyk users, the Open Source product and the Snyk Vulnerability Database already flag all versions of the affected packages. During the compromise, malicious tags were pushed with legitimate version numbers, and when the projects recovered, those same legitimate tags were dissociated from the malicious commits, so version numbers alone cannot determine whether an installed package is or was affected by this compromise. (See Indicators of Compromise and Detection and Scanning Guidance, above.) Run an immediate scan against any Composer-based repositories and pay close attention to monorepos and shared platform code.

If you determine that your project was not affected after reviewing your composer.lock, build, or install timing, and available indicators of compromise, you can use Snyk’s Ignore feature to stop this issue from appearing in future scans. See Snyk’s Ignore issues documentation for more details.

The Snyk CLI will automatically detect your Composer lockfile and detect vulnerable and malicious packages:

1snyk test

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 → Reports → Zero-Day → Active Security Incident Assessment for Laravel-Lang Supply Chain Attack.

Mitigation and remediation

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 commit.

• 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 share 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.

Lessons learned and defense in depth

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.

The official statement from the affected project, including details that call out GitHub, is available here: Official Statement on Incident.

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 status

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.