Laravel-Lang Supply Chain Attack Poisons Over 700 Package Versions via Packagist Tag Hijack, Deploying Cross-Platform Credential Stealer

Overview

An attacker compromised four widely-used Laravel localization packages on Packagist between May 22 and 23, 2026, exploiting a quirk in how the PHP package registry resolves Git tags from GitHub. Rather than modifying the official source repositories directly, the attacker rewrote existing release tags to point at malicious commits inside an attacker-controlled fork, poisoning over 700 historical versions across the four packages and delivering a cross-platform credential stealer to any developer or server that ran a fresh Composer install or upgrade. The attack was discovered and reported by Aikido Security and Socket Research Team, according to GBHackers.

What We Know

The Affected Packages

All four packages belong to the community-maintained laravel-lang namespace and provide localization strings for PHP applications built on Laravel. As Security Online notes, “The affected packages are not part of the official Laravel framework. They are third-party localization packages used by Laravel applications.” The packages are:

• laravel-lang/lang — the core translation-string bundle (7.8k GitHub stars), per GBHackers
• laravel-lang/http-statuses — localized HTTP status messages
• laravel-lang/attributes — model and form attribute translations
• laravel-lang/actions — localized action and verb messages

Aikido Security, which discovered the attack on May 22, 2026, confirmed 233 compromised versions across three of the four repositories. Including the fourth package, GBHackers and Snyk report that approximately 700 historical versions were poisoned across all four packages by May 23, 2026. Affected release lines span versions 12.x through 15.x, according to GBHackers.

The Attack Technique: Tag Rewriting via GitHub Forks

The attack exploited a structural property of the GitHub-to-Packagist publishing flow. As Snyk explains, the attacker “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.” This allowed malicious tags to masquerade as legitimate releases without ever merging malicious code into the official repositories.

BleepingComputer reports that, according to StepSecurity, “rather than publishing a new malicious version, the attacker rewrote every existing git tag in each repository to point at a new malicious commit.” The campaign began at 22:32 UTC against laravel-lang/lang, which holds 502 tags, and concluded by 00:00 UTC against laravel-lang/actions. Security Online notes that many versions appeared only “seconds apart, a pattern that is unusual for normal package maintenance and consistent with automated mass tagging or republishing.”

Because Packagist fetches package metadata by resolving Git tags from the linked GitHub repository, any developer running composer install or composer update against an affected version range would silently receive the malicious payload — with no visual indication that the source had changed.

The Payload: An Auto-Loading Credential Stealer

The malicious commits injected a file named src/helpers.php and registered it in composer.json under the autoload.files directive. As Snyk reports, “the backdoor executes automatically on every PHP request” once the package is installed — no explicit function call is required.

The first stage fetches a second-stage PHP payload from the command-and-control server at flipboxstudio[.]info/payload, then exfiltrates collected data to flipboxstudio[.]info/exfil. Security Online reports that the C2 domain was obfuscated using character codes at runtime and that TLS verification was disabled during payload retrieval to bypass security proxies.

According to Aikido Security, the second stage is an approximately 5,900-line PHP stealer with fifteen collector modules, which self-deletes after exfiltration to impede forensic analysis. On Windows systems, the payload drops an embedded executable named DebugChromium.exe to bypass Chrome’s App-Bound Encryption and extract browser-stored credentials, per Security Online.

The stealer targets a broad sweep of secrets, including:

• Cloud access credentials (AWS, GCP, Azure, DigitalOcean, Heroku, Vercel)
• Kubernetes configuration files and HashiCorp Vault tokens
• Jenkins and GitHub Actions CI/CD secrets
• SSH private keys and Git credentials
• Browser-saved passwords and session cookies
• Cryptocurrency wallet files and recovery phrases
• .env files, VPN configurations, and shell history

Response

Snyk reports that Packagist removed the malicious releases and temporarily unlisted all four packages on May 23, 2026, with investigation by Laravel-Lang maintainers, Packagist, and security researchers still ongoing at publication. GBHackers notes that “Packagist responded rapidly by taking down the malicious versions and temporarily unlisting the packages to prevent further installations.”

What We Don’t Know

The identity of the attacker or their affiliation has not been disclosed. It is not known how many production systems actually received and executed the malicious payload before Packagist removed the affected versions — the window of exposure spanned the evening of May 22 through the morning of May 23, 2026. The investigation by maintainers and researchers was still active at publication, and no official post-mortem or timeline for relisting the packages had been announced.

It is also unclear whether GitHub has taken any structural action to address the fork-tag resolution behavior that made the attack possible, or whether Packagist intends to implement additional validation to detect tag-rewriting events at publication time.

Analysis

The Laravel-Lang attack illustrates a category of supply-chain risk that differs from more familiar patterns like typosquatting or account takeover: the attacker never needed direct write access to the official repositories. By exploiting the mechanics of how Packagist resolves tags — delegating trust to GitHub’s tagging layer without validating the commit ancestry — they could poison hundreds of legitimate, pinned historical versions in a matter of hours.

The breadth of the credential stealer’s target list is particularly notable. A developer laptop or CI runner that installs a compromised version of any of these localization packages could simultaneously expose cloud infrastructure keys, container orchestration credentials, code signing tokens, and financial accounts — a single-point compromise with cross-environment blast radius. The self-deletion behavior and runtime obfuscation of the C2 domain show a level of operational care aimed at maximizing persistence and defeating reactive forensics.

Localization packages are a structurally attractive target: they are low-scrutiny (translation strings rarely trigger security reviews), widely installed across many application types, and updated regularly, meaning developers are accustomed to routine version bumps that could mask a malicious tag update.