Laravel-Lang Supply Chain Attack 2026: What Happened, Who's Affected, and What to Do Now

What Actually Happened: The Attack Vector Explained

Traditional supply chain attacks work by publishing new malicious package versions and hoping developers update into them. This attack was fundamentally different and more dangerous: the attacker gained write access to the GitHub repositories hosting the laravel-lang packages and force-pushed malicious commits to every existing tagged release. Version 13.0.0, which you installed six months ago and haven't touched since, now points at a different commit than it did when you installed it — a commit containing malware.

The four compromised packages are: laravel-lang/lang (the main localization package with 10M+ Composer installs), laravel-lang/attributes (form attribute translations), laravel-lang/http-statuses (HTTP status code translations), and laravel-lang/actions (common action label translations). The laravel-lang/lang package alone had 502 historical version tags rewritten.

The payload is delivered through a PHP loader injected into composer.json's autoload.files array. This is a particularly insidious delivery mechanism: autoload.files runs every single time your application loads the Composer autoloader — on every web request, every CLI command, every queue worker startup — without any explicit call in your application code. There is no function you have to call. There is no import you have to make. If the package is installed and composer autoload runs, the malware executes.

The malware performs three actions: it exfiltrates environment secrets (AWS, GCP, and Azure credentials, the GITHUB_TOKEN, container registry credentials, database passwords, API keys, CI/CD secrets — essentially everything accessible via $_ENV and getenv()), drops an ELF binary into /tmp (a persistent backdoor), and then self-deletes its own loader code to obstruct forensic analysis. The exfiltration target is a typosquatted domain (flipboxstudio.info — not the legitimate flipboxstudio.com) designed to evade casual network monitoring.

A separately discovered but related attack, named 'Megalodon' by security researchers, simultaneously targeted 5,561 GitHub repositories with malicious CI/CD workflow injection — poisoning the build pipeline itself to steal secrets during automated deployments. The timing correlation suggests a coordinated campaign rather than two independent incidents.

Am I Affected? How to Check Your Application Right Now

Any PHP application that includes laravel-lang/lang, laravel-lang/attributes, laravel-lang/http-statuses, or laravel-lang/actions as a Composer dependency should be treated as potentially compromised until verified otherwise. The window of potential exposure is any deployment or composer install/update that occurred between the attack beginning (22:32 UTC on May 21, 2026) and the package maintainers regaining control and pushing clean releases.

Step 1 — Check if the packages are installed:

Run in your project root: `composer show laravel-lang/lang laravel-lang/attributes laravel-lang/http-statuses laravel-lang/actions 2>/dev/null`

If any of these are installed, you need to proceed with all subsequent steps regardless of which version is shown — because the attack rewrote historical versions, not just the latest.

Step 2 — Verify the package integrity against the known-clean commit hashes:

Research the post-incident disclosure from StepSecurity (the firm that identified the attack) for the list of confirmed-safe commit hashes for each package version. Compare your installed package's actual commit hash against the verified clean list. Do not trust the version number alone — version numbers are tags, and tags are what was rewritten.

Step 3 — Check for the dropped binary:

Run: `ls -la /tmp/ | grep -E '\.(sh|bin|elf|x)$'` and look for recently created files with execute permissions. Also check cron jobs (`crontab -l`) for entries that weren't there before, and examine your web server's access logs for outbound connections to flipboxstudio.info.

Step 4 — Check CI/CD environment (for the Megalodon component):

Review your GitHub Actions workflow files for any changes you didn't make. Look specifically for new steps involving curl, wget, base64, or shell script execution from remote URLs. Audit recent Actions runs for unexpected external network calls.

Immediate Response Steps if You Are Affected

If you have confirmed or suspect compromise, the response sequence is time-sensitive. The longer stolen credentials remain valid, the greater the risk of secondary damage — unauthorized access to cloud infrastructure, data exfiltration from connected databases, or use of your AWS/GCP environment to launch attacks on others (which you may be liable for).

First priority — rotate all potentially exposed secrets immediately:

Rotate your AWS access keys and secret keys. Rotate GCP service account keys. Rotate your Azure service principal credentials. Regenerate your GitHub Personal Access Tokens and deploy keys. Rotate all database passwords. Regenerate API keys for any third-party services (Stripe, Twilio, SendGrid, etc.). Do not wait until you've confirmed whether credentials were actually captured — rotate them all now. The cost of rotating credentials you didn't need to is negligible. The cost of not rotating ones that were captured can be catastrophic.

Revoke and regenerate your Composer auth tokens if you have private package repository credentials stored in your environment.

Second priority — remove the compromised packages and reinstall clean versions:

1. Delete your vendor/laravel-lang directory completely 2. Run `composer clear-cache` 3. Update your composer.lock by running `composer update laravel-lang/lang laravel-lang/attributes laravel-lang/http-statuses laravel-lang/actions` 4. Verify the newly installed packages match the confirmed-clean commit hashes from StepSecurity's disclosure 5. Redeploy your application from a clean build

Third priority — check for the dropped binary and remove it:

Search all writeable directories (particularly /tmp, /var/tmp, /dev/shm) for the ELF binary. Look for processes running from /tmp with names resembling system utilities. If found, terminate the process and delete the binary, then audit what network connections that process made.

Fourth priority — audit your cloud infrastructure for unauthorized activity:

Review AWS CloudTrail, GCP Audit Logs, or Azure Activity Logs for any API calls made with your credentials that you don't recognize. Specifically look for: new IAM users or roles created, S3 bucket access from unusual IPs, EC2 instance launches in unexpected regions, and any calls to services you don't normally use. Your cloud provider's security team can assist with this audit if the scope is large.

Why This Attack is Different: The Supply Chain Trust Model is Broken

Traditional software security advice tells you to pin your dependencies to specific versions and verify package integrity. This attack demonstrates why that advice is insufficient for open source packages distributed through version control: if the version control system itself is compromised, pinning to a version number doesn't protect you, because the attacker simply moved the tag to point at their malicious commit.

Composer's security model relies on Packagist (the package registry) reflecting what GitHub hosts. The integrity verification Composer does by default checks that the downloaded code matches the hash recorded in composer.lock — but that hash was calculated from the malicious commit after the attack, not from the original clean code. A package lock file is not a guarantee of integrity against tag rewriting; it's only a guarantee against modification in transit between GitHub and your machine.

The more robust integrity verification that would have detected this: comparing installed package code against a hash recorded before the attack (e.g., from a Transparency Log), or using Composer's `--prefer-dist` with a private mirror that caches packages at known-good timestamps. Neither of these is common practice in the PHP ecosystem today, which is why this attack worked at scale.

The related Megalodon attack on CI/CD workflows points to a broader truth: your software supply chain is only as secure as every system that has write access to it. Package repositories, build pipelines, dependency management tools, and the authentication systems protecting them are all attack surfaces. The security perimeter for a modern software project extends far beyond the code your team writes.

For organizations running PHP in production: this incident should prompt a formal review of your Composer security practices, your secret management approach (are secrets stored in environment variables accessible to Composer autoload? they shouldn't be), and your CI/CD access controls (does your build pipeline have more access than it needs?).

Longer-Term: Hardening Your PHP Application Against Supply Chain Attacks

This incident, like every major supply chain attack before it, will fade from the news cycle within weeks. The organizations that emerge more resilient are the ones that use the urgency of the moment to implement practices they should have had in place already.

Implement Composer audit in your CI/CD pipeline: `composer audit` checks your installed packages against the PHP Security Advisories Database and fails the build if known-vulnerable packages are present. This doesn't catch zero-day supply chain attacks, but it catches the majority of publicly disclosed vulnerabilities automatically. It takes 30 seconds to add to a GitHub Actions workflow and there's no reason not to have it.

Use Composer's built-in integrity verification: `composer install --no-dev` in production, with `composer check-platform-reqs` to verify your environment matches what the packages expect. While not sufficient against tag rewriting, it catches the majority of simpler package tampering scenarios.

Adopt a secrets management solution that doesn't expose secrets to application code at boot time: HashiCorp Vault, AWS Secrets Manager, or GCP Secret Manager provide dynamic secret injection that limits exposure windows. The fundamental problem this attack exploited — all of your environment secrets being readable by every line of PHP running in your application — is a design choice, not a necessity.

Review and minimize Composer package permissions: does your application actually need all the packages in your composer.json? Over-installed dependencies are an expanded attack surface. Periodic audits of `composer show --direct` to review which packages your application actually uses — versus which were added speculatively — reduce the surface area for attacks like this one.

Implement network egress filtering for your application servers: the malware in this attack exfiltrated data over HTTP to a remote domain. If your application servers have egress filtering that only permits connections to known-required domains, the exfiltration either fails or produces an alert. Most cloud environments support security group rules and network ACLs that enable this. Most teams don't configure them.

For high-security applications: consider using a private Composer mirror (Satis or Packagist Enterprise) that caches packages at known-good timestamps. This doesn't prevent you from receiving attacks in new package versions, but it does prevent retroactive tag rewriting from affecting cached packages.

Frequently Asked Questions