The Real Repo Was Clean: Laravel-Lang Was Poisoned Through Git Tags Pointing at a Malicious Fork

The 2026 supply-chain wave that hit npm, PyPI, and VS Code extensions has now reached PHP and Composer. Researchers identified more than 700 malicious version tags published across the widely used Laravel-Lang project on May 22-23, 2026 — yet the official repositories were never modified. The attacker exploited a GitHub behavior in which a version tag can resolve to a commit in a fork, then pointed tags at a fork they controlled. A maintainer reviewing the real repository's commit history sees nothing wrong, because the trust unit that failed is the version tag, not the codebase.

SAN FRANCISCO, CALIFORNIA — On May 22, 2026, researchers detected a supply-chain attack against Laravel-Lang, a widely used PHP project that supplies localization files for the Laravel framework, and over the May 22-23 coverage cycle identified more than 700 malicious version tags published across several of its repositories — including laravel-lang/lang, laravel-lang/http-statuses, and laravel-lang/attributes, with the laravel-lang/actions package also named in some reporting. The defining detail is what the attacker did not do: no malicious code was committed to the official repositories. Instead, the operator abused a GitHub behavior in which a version tag can point to a commit living in a fork of the same repository, and created tags that resolved to commits inside a fork they controlled — poisoning the published package without ever altering the real codebase. Once installed, the payload auto-executes through Composer's autoloader and drops a roughly 5,900-line cross-platform PHP credential stealer organized into fifteen specialist collector modules. The compromise was documented by the research firm Socket, the application-security firm Aikido, The Hacker News, Cybersecurity News, and GBHackers, and no public reporting has tied it to a named threat actor.

What Happened

The Trust Unit That Failed Was the Version Tag

The most important fact about the Laravel-Lang compromise is the one that is easiest to miss: the attacker never committed malicious code to the official Laravel-Lang repositories. A maintainer or defender who opens laravel-lang/lang on GitHub and reads its commit history finds nothing wrong, because nothing in that history is wrong. The poisoning happened one layer up. GitHub allows a version tag to resolve to a commit that lives in a fork of the same repository rather than in the repository itself, and the attacker used exactly that behavior — creating tags that pointed at commits inside a fork they controlled. When Composer resolves a package by version, it follows the tag. The tag is the unit of trust that consumers actually rely on, and it is the unit the attacker subverted. The repository's code was clean the entire time, which is precisely why this technique defeats the most intuitive defender check.

More Than 700 Malicious Tags, Published Seconds Apart

Researchers identified more than 700 malicious version tags across the affected Laravel-Lang packages. Some counts describe roughly 233 distinct versions; the 700-plus tag figure and the ~233-version figure are different measurements — tags versus distinct version numbers — and the two have not been fully reconciled in public reporting, so the precise scope should be read against Socket's primary research rather than collapsed into a single number. What the reporting does agree on is the cadence: the malicious tags were published in rapid, automated succession on May 22-23, 2026, with many appearing only seconds apart. That tempo is a tell. Hundreds of tags created within seconds of one another is not manual maintenance work; it is scripted, machine-paced tag generation, designed to flood the affected packages with poisoned versions faster than any human review could keep up.

A 5,900-Line Stealer in Fifteen Modules

Once a poisoned Laravel-Lang version is installed, the payload does not wait to be called. It auto-executes through Composer's autoloader — the mechanism PHP projects use to load package code automatically — so simply pulling the dependency into a project is enough to run it. The payload itself is a roughly 5,900-line cross-platform PHP credential stealer that runs on Linux, macOS, and Windows, and it is organized into fifteen specialist collector modules, each responsible for a different class of secret. After collection, the modules' haul is encrypted with AES-256 and sent to flipboxstudio[.]info/exfil. The final step is the one that matters most for responders: the payload deletes itself from disk after sending the data, deliberately limiting the forensic evidence left behind on any host that ran it.

Scope and Impact

Laravel-Lang is not a fringe dependency. It supplies localization files for the Laravel framework and is pulled in by a large number of PHP projects through Composer and Packagist, which means the blast radius of a poisoned version is the developer machines, build servers, and continuous-integration runners of any team that installed one during the May 22-23 window. Several open questions still bound the scope, and this account should not imply otherwise: the total number of developers or servers that installed a poisoned version has not been reported, it is not publicly known whether any high-profile downstream projects pulled in a compromised version, and the inclusion of laravel-lang/actions among the affected packages is named in some reporting but not independently confirmed.

What is not in question is the pattern. The Laravel-Lang compromise lands in the middle of a 2026 supply-chain wave that has now crossed nearly every major package ecosystem. The CyberSignal has tracked the npm side of it closely — the Shai-Hulud worm now generating valid Sigstore provenance badges for its malicious packages, the copycat operator who pushed Shai-Hulud clones to npm within a week of the source leaking, the node-ipc package that shipped a stealer backdoor harvesting developer secrets, and the Megalodon campaign that backdoored thousands of GitHub repositories through their CI/CD workflows. The wave is not confined to one language. RubyGems suspended new signups in May 2026 in response to a mass-poisoning attack, and the Laravel-Lang case now extends the same logic to PHP and Composer.

Read alongside that cluster, the technique is the part worth keeping. The GitHub breach attributed to TeamPCP turned on a poisoned VS Code extension; Megalodon turned on poisoned workflow files; Shai-Hulud turned on poisoned npm packages. Each of those still involved planting something. The Laravel-Lang compromise is sharper, because the legitimate repository was never altered at all — the attacker poisoned the package purely by pointing version tags at a fork. The consistent soft target across the entire wave is not the source code. It is the registry, the tag, and the version number — the trust units that sit between a clean repository and the code a developer's machine actually runs.

Response and Attribution

For PHP and Laravel teams, the immediate work is an inventory. Audit composer.lock files across every project for any Laravel-Lang package, identify the exact installed versions, and determine whether any were pulled in during the May 22-23 window. If a poisoned version reached any developer machine or server, treat that host as fully compromised — the stealer harvests cloud credentials, Kubernetes and Vault tokens, CI/CD secrets, SSH keys, VPN configs, browser and password-manager data, and crypto wallets — and rotate every credential reachable from it. Pin dependencies to known-good versions published before May 22, re-install from a clean state, block outbound connections to flipboxstudio[.]info, and review egress logs for traffic to that domain. For DevSecOps and platform teams, the tag-to-fork technique carries a specific lesson: reviewing a package's official repository is no longer sufficient assurance, because a clean commit history can still ship a poisoned tag. Verify the commit a version tag actually resolves to, not just the state of the repository; enable real-time package scanning on composer install; and review whether your pipeline trusts Git tags implicitly.

For SOC and incident-response teams, the hunt is specific. Look for a PHP process spawning credential-collection activity during composer install, the creation of AES-encrypted data, outbound traffic to flipboxstudio[.]info, and then a self-delete from disk. Because the payload deliberately removes itself, forensic evidence on disk is limited by design, so prioritize network telemetry and Composer and CI logs over disk forensics, and treat any developer machine that ran a poisoned composer install as a credential-compromise incident rather than a malware cleanup. For CISOs, the strategic takeaway is the one the whole 2026 wave keeps repeating. Supply-chain risk is now genuinely cross-ecosystem — npm, PyPI, VS Code, RubyGems, and now PHP and Composer — and it is no longer defensible to treat it as an npm-only concern. The recurring lesson is that the registry, tag, and version trust unit is the soft target, not the source code, which means 'we reviewed the code' is no longer a sufficient supply-chain control.

The CyberSignal Analysis

Signal 01 — The Clean Repo Is the Whole Story

Most coverage of the Laravel-Lang compromise will frame it as another supply-chain attack and move on. The detail that deserves to lead is the one that makes it different: the legitimate repositories were never touched. The attacker poisoned the package entirely by abusing a GitHub behavior that lets a version tag resolve to a commit in a fork, then pointed tags at a fork they controlled. This defeats the single most intuitive defense a maintainer or security reviewer has — open the official repository, read the commit history, confirm it looks clean. In this case the commit history is clean, and the package is still poisoned. The trust unit that failed sits one layer above the code: the version tag. Any defense that stops at 'the repo looks fine' was never looking at the layer where this attack happened.

Signal 02 — Verify the Commit, Not the Repository

The actionable consequence of the tag-to-fork technique is narrow and concrete. A version tag is a pointer, and a pointer can aim at a commit that does not live in the repository you think you are trusting. For DevSecOps teams, that means the unit of verification has to move down a level: from 'is this repository clean' to 'what exact commit does this version tag resolve to, and does that commit live where I expect.' Practically, that argues for real-time package scanning at install time rather than periodic repository review, for pinning dependencies to known-good versions and verifying their resolved commits, and for treating implicit trust in Git tags as a gap in the pipeline. The Laravel-Lang case is a clean demonstration that a tag and the code it ships can quietly diverge.

Signal 03 — The Wave Is Cross-Ecosystem Now

It is no longer accurate to describe the 2026 supply-chain wave as an npm problem. Shai-Hulud and Megalodon hit the npm and GitHub Actions ecosystem; PyPI and VS Code extensions have been targeted; RubyGems suspended signups in response to a mass-poisoning attack; and the Laravel-Lang compromise now extends the same logic to PHP and Composer. The through-line across all of them is not a shared operator — no attribution links Laravel-Lang to any named group, and it should not be tied to one without evidence — but a shared conclusion that independent attackers keep reaching. The registry, the tag, and the version are the soft target, because that is the layer developers trust without inspecting. For a CISO, the takeaway is to stop scoping supply-chain security to one language's package manager and start treating every ecosystem the organization pulls code from as in scope.

Sources