Snyk Blog In this article TL;DR About the Affected Component Impacted Packages Known Timeline How the Compromise Happened Payload Behavior Indicators of Compromise Detection and Scanning Guidance Detecting the Laravel Lang Supply Chain Attack with Snyk Mitigation and Remediation Lessons Learned and Defense in Depth Snyk Status Laravel Lang Supply Chain Advisory Written by Brian Clark May 23, 2026 0 mins read Laravel-Lang Supply Chain Attack: 700+ Historical Packagist Versions Compromised 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. 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. 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 are currently treated as compromised. Packagist has unlisted the packages while remediation is in progress. Package Affected versions Purpose laravel-lang/lang > = 0.0.0 Bundled translation strings for Laravel applications. laravel-lang/http-statuses > = 0.0.0 Localized HTTP status code messages. laravel-lang/attributes > = 0.0.0 Translation strings for model and form attribute names. laravel-lang/actions > = 0.0.0 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. Known Timeline When (UTC) What happened May 22, 2026 First wave of malicious tags appears across the laravel-lang organization. An early snapshot catalogs roughly 233 poisoned versions across the four packages. May 22 to 23, 2026 Republication of historical tags continues in bursts, with multiple repositories receiving rewrites within seconds of each other. Total count climbs past 700 versions. May 23, 2026 Packagist removes the malicious releases and temporarily unlists the four packages. Public reporting and IoCs are shared by the wider research community. Ongoing Snyk continues to monitor the incident; investigation by the Laravel-Lang maintainers, Packagist, and external researchers is still in progress. How the Compromise Happened 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. 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. Indicator type Value Command and control domain flipboxstudio [ . ] info Second-stage payload URL https://flipboxstudio\[.\]info/payload Exfiltration endpoint https://flipboxstudio\[.\]info/exfil Malicious source file src/helpers.php (registered via composer.json autoload.files) Infection marker file < tmp > /.laravel _ locale/ < md5 _ hash > Dropped stealer (any OS) < tmp > /.laravel _ locale/ < 12 random hex > .php Windows launcher script < tmp > /.laravel _ locale/ < 8 random hex > .vbs Windows artifact DebugChromium.exe Suspicious runtime behavior Outbound network requests to flipboxstudio [ . ] info; reads from /var/run/secrets/ and /proc/ [ pid ] /environ; background php or cscript process execution. Detection and Scanning 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. Detecting the Laravel Lang Supply Chain Attack with Snyk 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: 1 snyk 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 > Remediation > Zero Day Report to see if you’re impacted. 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 pac