Laravel Lang supply-chain attack

Executive summary

Between 22 and 23 May 2026, attackers compromised the Laravel-Lang GitHub organization by rewriting release tags to malicious fork commits — a technique that bypasses casual review of the default branch. Affected packages include the widely used localization libraries listed below. Because the backdoor is wired through Composer's autoload.files, it executes during normal application runtime whenever a compromised version is installed.

Industry analysis (Socket, Aikido, StepSecurity) describes a multi-stage dropper that pulls a large PHP stealer from flipboxstudio.info, targets fifteen categories of secrets, encrypts results, and phones home before self-deleting. Treat any host that resolved a bad tag as potentially compromised — not merely “exposed.”

Attack chain

• Attackers did not need a commit on the default branch — they exploited GitHub tags pointing to malicious fork commits, so `composer require` / `composer update` pulled trojanized releases via Packagist.
• Each poisoned release adds `src/helpers.php` and registers it under `autoload.files` in composer.json — Composer loads the file automatically at runtime, no explicit import required.
• The dropper fetches a ~5,900-line PHP payload from flipboxstudio[.]info/payload (SSL verification disabled), then executes a modular credential stealer with fifteen collector modules.
• Collected secrets are AES-256 encrypted and exfiltrated to flipboxstudio[.]info/exfil; the stealer deletes itself from disk to reduce forensic evidence. On Windows, a .vbs launcher may be dropped.

What the payload hunts

• Cloud metadata and IAM credentials (AWS, GCP, Azure-style environment patterns)
• CI/CD secrets, `.env` files, and `/proc/[pid]/environ` process environment reads
• Kubernetes service-account tokens and `/var/run/secrets/` mounts
• HashiCorp Vault tokens, database connection strings, and SSH private keys
• Browser profiles, password-manager vault paths, npm/GitHub tokens, and 1Password-related material per industry analysis

Organisational impact

• Any Laravel or PHP project that resolved a compromised laravel-lang/* tag — including pinned semver ranges that still map to rewritten tags — should treat build runners, staging, and production hosts as potentially compromised.
• The attack is silent at install time for many teams: autoload.files executes during normal app bootstrap, including web requests and queue workers, not only during composer install.
• Organizations without Laravel Lang are not directly affected, but the tag-rewrite technique applies to any GitHub-hosted package — review dependency provenance and lockfile integrity org-wide.
• Expect follow-on abuse of stolen CI tokens for further supply-chain pushes; rotate secrets even if outbound C2 was blocked.

First 72 hours — response checklist

• Search composer.lock for laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes, and laravel-lang/actions — compare resolved versions against maintainer advisories and block until clean tags are confirmed.
• Hunt filesystem markers: `/.laravel_locale/` directory, random `.php` / `.vbs` droppers, and outbound DNS/HTTP to flipboxstudio.info on app servers and CI runners.
• Review CI logs for background php/cscript execution, reads of cloud metadata IP 169.254.169.254, and suspicious package install activity in the 22–23 May 2026 window.
• Rotate all secrets present on affected runners: cloud keys, database passwords, Vault tokens, GitHub/GitLab PATs, npm tokens, and kubeconfig credentials.
• Pin dependencies to known-good commit SHAs or internal mirrors; enable Composer `--prefer-source` audit only after verifying tag integrity with maintainers.
• Rebuild and redeploy from clean lockfiles; preserve disk images for forensics if exfiltration is suspected.