Cross‑Platform Credential Stealer Spread via Compromised Laravel‑Lang PHP Packages

Key Takeaways

• A supply‑chain compromise targeted the Laravel‑Lang organization, affecting four popular PHP packages.
• Attackers did not modify source code; instead they rewrote existing Git tags to point to malicious commits containing a backdoor file (src/helpers.php).
• The backdoor is autoloaded on every PHP request, enabling silent execution without any user interaction.
• Once activated, the malware drops a cross‑platform credential stealer that harvests cloud, CI/CD, cryptocurrency, browser, password‑manager, VPN, and development‑environment secrets.
• Collected data is AES‑256 encrypted and exfiltrated to flipboxstudio[.]info/exfil, after which the payload self‑deletes to hinder forensics.
• Over 700 fraudulent tags were published in rapid succession, suggesting the attacker gained organization‑level credentials or compromised release infrastructure.
• Mitigation requires auditing Composer dependencies, pinning exact versions, monitoring for unexpected tag changes, and employing integrity‑checking tools (e.g., Sigstore, SLSA).

Overview of the Incident
On May 22‑23 2026, cybersecurity researchers disclosed a fresh software supply‑chain attack that abused the Laravel‑Lang PHP ecosystem. The compromised packages—laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes, and laravel-lang/actions—are widely used for localisation, HTTP status handling, attribute definitions, and action abstractions in Laravel applications. Rather than injecting malicious code directly into the repositories, the threat actor altered existing Git tags so each tag pointed to a newly crafted commit containing a hidden backdoor. This technique allowed the attacker to distribute the malware through seemingly legitimate version releases, bypassing typical code‑review scrutiny that focuses on source‑code changes.

How the Attack Was Executed
The attackers are believed to have obtained organization‑level access—perhaps through stolen credentials, compromised CI/CD pipelines, or a breach of the release infrastructure—enabling them to rewrite tags en masse. More than 700 fraudulent tags appeared within seconds of each other, indicating an automated process rather than manual tampering. By pointing each tag to a malicious commit, the attacker ensured that any developer or CI system pulling a specific version would unknowingly fetch the compromised code. Notably, the actual source files of the packages remained untouched; only the tag objects were altered, a stealthy approach that evades many traditional vulnerability scanners that compare file hashes against known-good versions.

The Autoloaded Backdoor
The malicious commit introduced a file named src/helpers.php. This file was added to the autoload.files section of each package’s composer.json. Composer’s autoloader automatically includes every file listed in autoload.files during the startup of any PHP application that runs require __DIR__.'/vendor/autoload.php'. Consequently, as soon as a Laravel (or any Symfony‑based, PHPUnit, or other PHP framework) application boots, the backdoor executes without requiring class instantiation, method calls, or any explicit trigger. This “zero‑click” activation mechanism maximizes the attack surface: every request, console command, or test run that loads the Composer autoloader will inadvertently launch the malware.

Payload Delivery and Execution Flow
src/helpers.php acts as a dropper. Upon execution, it generates a unique per‑host identifier—an MD5 hash derived from the current directory path, system architecture, and inode—to ensure the malicious payload runs only once per machine, reducing the chance of detection through repeated activity. The dropper then contacts the external server flipboxstudio[.]info to retrieve a ~5,900‑line PHP credential‑stealer. On Windows hosts, the dropper writes a Visual Basic Script launcher and executes it via cscript.exe; on Linux and macOS, it uses PHP’s exec() function to run the stealer directly. Because the stealer is fetched at runtime, the initial package contains only a small loader, making static analysis less likely to flag it as malicious.

Capabilities of the Credential Stealer
The retrieved stealer is organized into fifteen specialist collector modules, each targeting a distinct class of secrets. It harvests:

• Cloud metadata and credentials from IAM roles, Google Cloud ADC, Azure access tokens, and Kubernetes service accounts.
• CI/CD tokens and configurations for GitHub Actions, GitLab Runners, CircleCI, TravisCI, Jenkins, ArgoCD, and similar platforms.
• Cryptocurrency wallet seed phrases and files (Electrum, Exodus, Atomic, Ledger Live, Trezor, Wasabi, Sparrow) and browser‑based wallet extensions (MetaMask, Phantom, Trust Wallet, Ronin, Keplr, Solflare, Rabby).
• Browser data—history, cookies, login credentials—from Chrome, Edge, Firefox, Brave, and Opera, using a Base64‑encoded Windows executable that circumvents Chromium’s app‑bound encryption.
• Password‑manager vaults for 1Password, Bitwarden, LastPass, KeePass, Dashlane, and NordPass.
• VPN configurations and saved logins for OpenVPN, WireGuard, NetworkManager, NordVPN, ExpressVPN, CyberGhost, and Mullvad.
• Development artifacts such as Docker auth tokens, SSH keys, Git credentials, .env files, wp-config.php, docker‑compose.yml, shell and database histories, and global/local .gitconfig, .git-credentials, and .netrc files.
• Communication‑app session tokens from Discord, Slack, and Telegram, as well as email client data from Outlook and Thunderbird.
• Remote‑access artefacts including PuTTY/WinSCP sessions, RDP files, and Windows Credential Manager dumps.

After gathering this information, the stealer encrypts the exfiltrate with AES‑256, transmits it to flipboxstudio[.]info/exfil, and then deletes itself from disk to impede forensic recovery.

Impact and Potential Harm
Because the backdoor runs on every PHP request, any server, developer workstation, or CI agent that consumes a compromised Laravel‑Lang version becomes an immediate data‑exfiltration vector. The breadth of harvested secrets—ranging from cloud admin credentials to cryptocurrency keys—means a single compromised host can facilitate lateral movement, privilege escalation, financial theft, and further supply‑chain poisoning. Enterprises that rely on Laravel for internal tools, public‑facing websites, or automation pipelines are especially at risk, as the stealer can quietly harvest credentials used to access production environments, source‑code repositories, and deployment systems.

Detection and Mitigation Strategies
Detecting this attack requires vigilance beyond typical vulnerability scanning:

• Dependency Pinning and Lock‑file Auditing – Enforce exact versions in composer.lock and regularly compare lock files against known-good baselines. Tools like composer audit or third‑party SBOM scanners can flag unexpected changes.
• Tag Integrity Monitoring – Monitor Git tag histories for anomalous patterns (e.g., dozens of tags created within seconds). Services that provide signed tag verification (e.g., Sigstore, GitHub’s commit signing) can detect unauthorized retagging.
• Runtime Behavior Analysis – Deploy endpoint detection and response (EDR) solutions that watch for spontaneous execution of src/helpers.php or outbound connections to unfamiliar domains like flipboxstudio[.]info.
• Least‑Privilege Principles – Limit Composer’s access to private repositories and CI secrets; use scoped tokens with minimal required scopes.
• Network Controls – Block outbound traffic to known malicious domains and enforce DNS filtering or proxy inspection to catch exfiltration attempts.
• Incident Response Preparation – Maintain immutable backups of critical credential stores and regularly rotate secrets, especially cloud and CI/CD tokens, to limit the window of usefulness for stolen data.

Organizations should also consider adopting supply‑chain security frameworks such as SLSA (Supply‑chain Levels for Software Artifacts) to enforce build provenance and prevent unauthorized tag manipulation.

Conclusion
The Laravel‑Lang supply‑chain incident illustrates how attackers can abuse trust in package repositories without touching the original source code. By manipulating Git tags to point to malicious commits, they leveraged Composer’s autoloading mechanism to achieve silent, widespread execution of a sophisticated credential stealer. The attack’s scale—hundreds of fraudulent tags released in rapid succession—underscores the need for stronger integrity guarantees around release processes, improved monitoring of tag activity, and rigorous dependency‑management practices. As software supply chains continue to be a lucrative target, adopting layered defenses—from cryptographic signing of releases to runtime anomaly detection—will be essential to thwart similar campaigns in the future.