Laravel-Lang Supply Chain Attack: How to be Safe

A comprehensive deep-dive into the May 2026 credential-stealing campaign that compromised 700+ Composer packages — and what every Laravel developer needs to do about it.

What Happened

Between May 22 and May 23, 2026, a sophisticated supply chain attacker compromised four widely-used Laravel localization packages published under the laravel-lang/* namespace on Packagist. The attacker republished malicious versions under approximately 700 historical release tags, injecting a two-stage malware chain that automatically executed on every PHP request in any application that installed or updated one of the affected packages.

The payload — a 5,900-line credential stealer — harvested cloud keys, Kubernetes and Vault secrets, CI/CD tokens, SSH keys, browser-stored credentials, password manager vaults, cryptocurrency wallets, and messaging platform tokens. Every piece of stolen data was encrypted and exfiltrated to a command-and-control server at flipboxstudio[.]info.

The bottom line: any environment that pulled an affected version during the compromise window should be treated as fully compromised until proven otherwise.

Attack Timeline

Affected Packages

How the Attack Worked (Technical Breakdown)

Entry Vector: The attacker gained access to the compromised repositories through a leaked GitHub Personal Access Token (PAT), which researchers believe was exposed during a recent GitHub data breach. Crucially, the malicious code was never committed to the official repositories directly. GitHub allows version tags to point to commits from a fork of the same repository. The attacker exploited this by creating tags in the official repos that pointed to malicious commits inside a fork under their control.

Once a malicious tag was in place, any Composer install that resolved to one of the affected versions would pull down the attacker's code. The legitimate repositories, including all prior commits, remained untouched — making the tampering harder to detect through casual code review.

Stage 1:The Dropper

The attacker introduced a file called src/helpers.php and registered it in composer.json under the autoload.files key. This is the critical design choice that made the attack so effective:

JSON

{

    "autoload": {

        "files": ["src/helpers.php"]

    }

}

Composer's autoloader unconditionally requires every file listed under autoload.files at the very start of the PHP request lifecycle — before any application code runs. This means the malicious code fires on every single request, including:

• Web requests
• Artisan console commands
• Background queue workers
• Scheduled tasks
• Horizon processes

Stage 2: The Credential Stealer

The second-stage payload was a massive ~5,900-line PHP credential stealer organized into fifteen specialist collector modules. After harvesting everything it could find, it:

1. Encrypted all collected data using AES-256
2. Exfiltrated the encrypted payload to https://flipboxstudio[.]info/exfil
3. Self-deleted the dropped files from disk to limit forensic evidence

5. What the Stealer Harvested

The stealer was remarkably thorough. Here is the complete catalog of targeted assets:

Cloud Credentials

• AWS — Access keys, secret keys, session tokens from environment variables, ~/.aws/credentials, and live EC2 instance metadata (169.254.169.254)
• GCP — Application default credentials, access token databases, all named CLI configurations
• Azure — Access tokens, MSAL cache, service principal profiles
• Other platforms — DigitalOcean, Heroku, Vercel, Netlify, Railway, and Fly.io auth tokens

Infrastructure Secrets

• All kubeconfig files, including /etc/kubernetes/admin.conf
• HashiCorp Vault tokens
• Helm repository configurations
• Docker config.json authentication files

Developer Credentials

• SSH private keys and known_hosts data
• All .git-credentials and .gitconfig files
• .netrc, .npmrc, .yarnrc, .pypirc, .gem/credentials, .composer/auth.json
• GitHub CLI, GitLab CLI, and Hub CLI authentication tokens
• Shell history files (bash, zsh, psql, mysql, python, node)
• All .env files and configuration files found by recursively scanning the working directory (wp-config.php, settings.py, docker-compose.yml, secrets.yaml, and more)

Browsers and Password Managers

• 17 Chromium-based browsers — Chrome, Edge, Brave, Opera, Opera GX, Vivaldi, Chromium, Yandex, and more (includes a Windows helper executable to decrypt DPAPI-protected login databases)
• Firefox & Thunderbird — logins.json and key4.db across all profiles
• KeePass — .kdbx and .kdb database files
• 1Password and Bitwarden — Local vault files

Cryptocurrency Wallets

• Bitcoin, Ethereum, Monero, Litecoin, Dash, Dogecoin, and Zcash wallet files
• Electrum, Exodus, Atomic, Ledger Live, Trezor, Wasabi, and Sparrow wallets
• Browser extension wallets by ID: MetaMask, Phantom, Trust Wallet, Ronin, Keplr, Solflare, and Rabby

Windows-Specific

• Windows Credential Manager and Vault entries
• PuTTY and WinSCP saved sessions (WinSCP passwords actively decrypted)
• .rdp files from Desktop, Documents, and Downloads
• Outlook registry profiles, OST/PST file inventory
• A dropped artifact named DebugChromium.exe observed on infected systems

Communication Platforms

• Slack tokens
• Discord bot tokens
• Telegram bot tokens

VPN Configurations

• Config files and extracted credentials for NordVPN, ExpressVPN, ProtonVPN, CyberGhost, Private Internet Access, Windscribe, Mullvad, Surfshark, WireGuard, and OpenVPN

How to Know If You're Affected

File System Checks

Run these checks on every host that runs Laravel applications:

Linux / macOS:

# Look for the infection marker directory

ls -la /tmp/.laravel_locale/

ls -la $TMPDIR/.laravel_locale/

# Search for malicious helpers.php in vendor

find vendor/laravel-lang -name "helpers.php" -path "*/src/*" 2>/dev/null

Windows: PowerShell

# Check for the infection marker

dir %TEMP%\.laravel_locale\

# Search for dropped VBS launchers

dir %TEMP%\.laravel_locale\*.vbs

# Search for the stealer artifact

dir /s DebugChromium.exe

Composer Lock Audit: Bash

# Search for affected packages in composer.lock

grep -A5 "laravel-lang" composer.lock

# Check if autoload.files references helpers.php

grep -r "helpers.php" vendor/laravel-lang/*/composer.json 2>/dev/null

Red flag: A legitimate localization package has no reason to ship a helpers file that auto-loads on every request. If you find one, treat the host as compromised.

Network Log Analysis

Check DNS, proxy, and firewall logs for any connections or lookups to:

• flipboxstudio.info
• flipboxstudio.info/payload
• flipboxstudio.info/exfil

Block this domain immediately at your DNS resolver and perimeter firewall. Even a single resolution attempt is a strong signal of compromise.

EDR / Endpoint Monitoring

Hunt for these suspicious behaviors:

• Unexpected background PHP or cscript process execution
• Reads from /var/run/secrets/ and /proc/[pid]/environ on Linux/macOS
• Any process spawning from temporary directories with randomly-named PHP or VBS files

Automated Scanning

• Snyk users: Run snyk test against your Composer-based repositories. For enterprise plans, check Analytics → Reports → Zero-Day → Active Security Incident Assessment.
• Aikido users: Check your central feed and filter on malware issues. This surfaces as a 100/100 critical issue. Trigger a manual rescan for immediate results.

9. Prevention: Building Defense-in-Depth

This incident is a powerful reminder that a package's trust boundary is not the source repository — it's the entire chain of systems between a developer's commit and the artifact your application actually installs.

For All Laravel Developers

• Verify content integrity at install time. Composer records package content hashes in composer.lock. Use composer install --no-cache in CI and verify integrity hashes to make tampering visible. Never run composer update in production — always use a locked, reviewed composer.lock.
• Audit autoload.files entries regularly. Any package that registers files for auto-execution on every request deserves scrutiny. Run:

Bash

composer dump-autoload --strict-psr

• Pin exact versions and use composer.lock. Avoid floating version constraints (^, ~) for critical dependencies in production. Commit your composer.lock and review it in pull requests.

• Use private package mirrors / proxies. Tools like Private Packagist, Satis, or a local Composer proxy give you a controlled, auditable copy of packages.

• Adopt egress controls in build and production environments. CI runners and production containers should not be able to reach arbitrary internet domains. An allowlist approach would have completely blocked the second-stage download in this attack.

• Use short-lived, scoped secrets. Long-lived credentials sitting in .env files magnify the damage from any in-process secret theft. Where possible, use instance metadata services, secret managers, or OIDC-based authentication.

• Monitor for suspicious package changes. Use tools like:

             -Snyk — Open source vulnerability and malware scanning

             -Aikido — Malware detection for dependencies

             -Aikido Safe Chain (open source) — Intercepts npm/npx/yarn commands and checks against threat intelligence before install

Lock down repository access.

• Enforce hardware-backed MFA on GitHub/GitLab
• Use fine-grained PATs with minimum scope
• Review who can push tags and publish packages
• Enable branch/tag protection rules