Laravel-Lang Supply Chain Attack: Attackers Rewrote 700+ Git Tags Across Four Packages to Silently Boot a 15-Module PHP Credential Stealer on Every Application Startup

What happened

Researchers at Socket, StepSecurity, and Aikido Security flagged a coordinated supply chain attack targeting the Laravel-Lang organization on Packagist, the PHP package registry. The campaign struck on May 22 and 23, 2026, and rather than modifying existing source code in the repositories, the attackers took a more surgical approach: they rewrote every existing git tag in each affected repository to point to a new malicious commit while leaving the actual project source files intact. This technique means that source code audits of the repositories would return clean results, and only a careful examination of what each tag actually references would reveal the tampering.

The affected packages are four of the most widely-deployed Laravel-Lang libraries:

1. laravel-lang/lang
2. laravel-lang/http-statuses
3. laravel-lang/attributes
4. laravel-lang/actions

The volume of malicious tags published in this campaign is staggering. More than 700 version tags were identified across these packages, appearing in rapid succession with many published only seconds apart. This automated, high-volume tagging behavior is a strong indicator that the attacker had direct access to the organization's release infrastructure, repository automation systems, or organization-level credentials rather than obtaining access to a single package maintainer account. Socket described the timing and pattern as pointing to a broader compromise of the Laravel-Lang organization's release process as a whole.

The core malicious payload lives in a file named src/helpers.php that is embedded into each compromised version tag. What makes this particularly insidious is how it activates. The attacker registered this file in each package's composer.json under the autoload.files mapping. This means that because every Laravel application calls require __DIR__.'/vendor/autoload.php' on startup, and because Symfony, PHPUnit, and most other PHP frameworks do the same, the payload runs the moment any consumer of the affected package boots. There is no class to instantiate, no method to call, no HTTP request to process. The malware simply fires the instant the application initializes.

Before reaching out to its command-and-control infrastructure, the dropper generates a unique per-host marker by computing an MD5 hash combining the directory path, system architecture, and inode. This ensures the payload triggers only once per machine, which prevents redundant executions and makes the malware significantly harder to detect through behavioral repetition patterns. The dropper then contacts the attacker's server at flipboxstudio[.]info to retrieve the actual stealer payload.

The delivery mechanism varies by operating system. On Windows systems, Aikido Security confirmed that the dropper delivers a Visual Basic Script launcher and executes it through cscript. On Linux and macOS, the stealer payload is executed directly through exec(). In all cases, the result is the same: a PHP-based cross-platform credential harvester runs on the compromised system.

The stealer itself is approximately 5,900 lines of PHP organized into fifteen specialist collection modules. After harvesting everything it can find, it encrypts the results using AES-256 and transmits them to flipboxstudio[.]info/exfil. It then removes itself from disk to limit the forensic footprint available to investigators.

What the stealer collects

The credential stealer covers an exceptionally broad attack surface. The fifteen collection modules target:

1. Cloud metadata including IAM roles, instance identity documents, and cloud provider credentials (AWS, Google Cloud, Azure, DigitalOcean, Heroku, Vercel, Netlify, Railway, Fly.io)
2. Kubernetes Service Account tokens and Helm registry configurations
3. HashiCorp Vault tokens
4. CI/CD credentials from Jenkins, GitLab Runners, GitHub Actions, CircleCI, TravisCI, and ArgoCD
5. Cryptocurrency wallet seed phrases and files for Electrum, Exodus, Atomic, Ledger Live, Trezor, Wasabi, and Sparrow
6. Browser extension wallets including MetaMask, Phantom, Trust Wallet, Ronin, Keplr, Solflare, and Rabby
7. Browser history, cookies, and login data from Chrome, Edge, Firefox, Brave, and Opera using a Base64-encoded embedded Windows executable that bypasses Chromium's app-bound encryption protections
8. Password manager local vaults and browser extension data for 1Password, Bitwarden, LastPass, KeePass, Dashlane, and NordPass
9. PuTTY and WinSCP saved sessions
10. Windows Credential Manager dumps and RDP configuration files
11. Session tokens from Discord, Slack, and Telegram
12. Email client data from Microsoft Outlook and Thunderbird, and FTP client configurations from FileZilla, WinSCP, and CoreFTP
13. Infrastructure configuration files including Docker auth tokens, SSH private keys, Git credentials, shell history, database history, Kubernetes cluster configs, .env files, wp-config.php, and docker-compose.yml
14. Environment variables loaded into the PHP process at the time of execution
15. VPN configurations and saved credentials for OpenVPN, WireGuard, NetworkManager, NordVPN, ExpressVPN, CyberGhost, and Mullvad

The breadth of this collection capability reflects a deliberately comprehensive approach to credential harvesting. The attacker is not targeting a single category of credentials. They are attempting to walk away with every key, token, secret, and session identifier present on the compromised host.

Who is affected

Any PHP application that depends on one of the four compromised Laravel-Lang packages and installed or updated to a version with a malicious git tag is affected. Given that laravel-lang/lang in particular is a foundational dependency for a large number of Laravel applications, the potential reach of this campaign is substantial.

Because the payload executes on application startup through the Composer autoload mechanism, there is no need for an HTTP request to be processed or any user interaction to occur. A deployment pipeline that pulls a fresh composer install, a container build that installs dependencies, or a developer workstation running composer update are all sufficient to trigger execution.

The self-deletion behavior means that by the time a compromised system is inspected, the stealer payload itself may no longer be present. The indicator of compromise to look for is therefore not the presence of the malware on disk but rather evidence of network contact with flipboxstudio[.]info and any changes to the git tags in your local package cache.

Risk level

Critical

The combination of automated execution on every application startup, broad distribution through a trusted package registry, a comprehensive 15-module credential harvester, and self-deletion to defeat forensic analysis makes this a high-consequence supply chain compromise. The specific targeting of cloud credentials, Kubernetes configurations, and CI/CD tokens is notable because these are the credentials that enable lateral movement beyond the initial compromised host into cloud infrastructure, production environments, and downstream software pipelines. An organization whose Laravel application was running a compromised version of these packages may not just have a credential compromise on one server. They may have handed an attacker the keys to their entire infrastructure.

What to do

1. Audit your composer.lock files immediately to determine whether any of the four affected packages are present and which version tags they resolve to. Check whether the resolved tags point to commits that include src/helpers.php in the autoload.files configuration
2. Check your systems' DNS and network logs for outbound connections to flipboxstudio[.]info. Any such connection should be treated as a confirmed compromise indicator requiring immediate incident response
3. Run the git tag verification commands against your locally cached copies of these repositories to confirm whether the tags you are running against have been rewritten
4. If any compromise indicators are found, rotate all credentials that were present on the affected systems, including cloud provider credentials, CI/CD tokens, database passwords, SSH keys, and any secrets stored in environment variables or .env files
5. Update your composer.json to pin to verified clean version tags or migrate to explicit commit hashes rather than version tags for these packages
6. If the payload ran on a CI/CD runner, treat all secrets accessible to that runner as compromised and rotate them before the next pipeline execution
7. Review your container images built during the May 22 to 25 window for dependencies on these packages, as images built during this period may have been built with compromised versions

Analysis

The decision to rewrite existing git tags rather than alter source code is a deliberate evasion technique that exploits a common blind spot in software supply chain security: most security review processes focus on source code changes, not on verifying that version tags continue to point to the same commits they did when initially published. The attack surface that this campaign exploits has been discussed in the security research community for years, and this is a clean real-world example of it being leveraged at scale.

The per-host MD5 fingerprinting mechanism is another indicator of operational maturity. A stealer that runs on every startup would generate repeated network contact events that are far more likely to be detected by security monitoring tools. The one-execution-per-host design limits that exposure while still ensuring that credentials are captured on the first run.

The breadth of the collection modules is worth examining as a signal of what the attacker was prioritizing. The explicit targeting of cloud metadata endpoints, Kubernetes service account tokens, and CI/CD provider credentials suggests an attacker whose primary goal is infrastructure access and supply chain position rather than simple credential resale. Cloud credentials and CI/CD tokens obtained from a Laravel application's deployment environment can be used to access production infrastructure, inject malicious code into downstream software builds, and propagate access to other organizations that depend on the compromised pipeline. The cryptocurrency wallet collection modules are a parallel revenue stream, but the cloud and CI/CD targeting is what makes this campaign particularly concerning for organizations with any significant cloud footprint.

The timing of the attack, with tags published on May 22 and 23 and each appearing seconds apart, indicates automation that is consistent with someone who had already scripted the entire campaign before gaining access. This was not an opportunistic exploitation of a newly discovered access path. It was a planned operation that was executed quickly and systematically once the attacker had the access they needed.