Saturday morning. I opened Twitter and saw a tweet about the Laravel-Lang packages being compromised.

My first reaction was simple: "I don't use that package."

Then I opened composer.json on a project I work on and found this in require-dev:

"laravel-lang/lang": "^14.8",
"laravel-lang/publisher": "^16.8",

That changed things.

What Actually Happened

The attack used laravel-lang packages as the distribution channel. And the sneaky part: the main repository branch looked completely clean. No suspicious commits, no new code. The malicious payload was pushed via git tags on forks.

Most developers would not notice anything. Just a routine composer update, same as always.

Once installed, the payload executed at autoload time. That means every php artisan command, queue worker, or web request running that codebase triggered the malware the moment PHP hit require_once __DIR__.'/../vendor/autoload.php' in public/index.php. Silently. No error, no red screen, nothing.

The malware was a credential stealer. It searched the machine for:

• .env files from Laravel projects
• AWS access keys and session tokens
• SSH private keys
• GitHub CLI tokens
• NPM tokens
• Infrastructure secrets

This is not a SQL injection that messes with your database rows. This is a key stealer that runs on your machine and takes everything it finds.

Aikido Security caught it and reported it to Packagist. Packagist removed the affected versions. But if you ran composer update during that window, you were exposed.

Why Supply Chain Attacks Are Different

Classic Laravel security talks about SQL injection, XSS, CSRF. Those are attacks that come from outside users sending malicious input to your application.

Supply chain attacks come from inside your own development process. The attacker does not need to find a vulnerability in your code. They need to compromise one developer account at one package maintainer. Every project depending on that package is now exposed.

With AI tools, these attacks are getting more sophisticated and more frequent. The JavaScript ecosystem has been dealing with hundreds of similar incidents. PHP is catching up, unfortunately.

What I Actually Changed

On a project I work on, we run composer update on a regular schedule. After this incident, I sat down and wrote it all out.

The full workflow now looks like this:

# 1. Run composer update inside Docker
docker compose exec app composer update

# 2. Pin exact versions using jack raise-to-installed
docker compose exec app vendor/bin/jack raise-to-installed --dry-run  # preview first
docker compose exec app vendor/bin/jack raise-to-installed             # apply

# 3. Update lock hash
docker compose exec app composer update --lock

# 4. Commit everything
git add composer.json composer.lock
git commit -m "chore: update dependencies"

rector/jack is a tool by the Rector team that handles version management in composer.json. The raise-to-installed command takes whatever is currently installed and raises the constraints to match exactly. Instead of "guzzlehttp/guzzle": "^7.10", you get "guzzlehttp/guzzle": "^7.11". Each future composer update will only reach what you explicitly allow. This is not standard Composer practice. It trades upgrade convenience for a narrower blast radius on unexpected jumps.

One gotcha we hit: on a Laravel 10 project, bare composer update can fail with an advisory block. The fix is to add this to composer.json config:

"config": {
    "audit": {
        "abandoned": "report"
    },
    "policy": {
        "advisories": {
            "block": false
        }
    }
}

Advisories are reported, not blocking. You still see them and still have to act on them. The update just runs.

Always verify what got bumped before committing. On that project, it runs PHP 8.1, so packages that require 8.2+ cannot be allowed in. After raise-to-installed dry run, check that nothing jumped to a version with a higher PHP floor.

One important caveat: this workflow would not have prevented the Laravel-Lang incident itself. By the time jack raise-to-installed runs, the infected version is already installed. raise-to-installed then pins that infected version as the new baseline. The actual defenses at install time are limited. composer audit helps against known advisories, but not against a malicious package that was compromised minutes ago. Run it anyway. Watch community reports before you update.

composer audit

Before updating, run:

composer audit

It checks installed packages against the PHP Security Advisories Database. On a fresh project, nothing shows up. On an older one, you might see something like:

Found 3 security vulnerability advisories affecting 2 packages:

Package symfony/http-kernel
CVE-2026-XXXXX: ...

Package league/commonmark
CVE-2026-XXXXX: ...

Run it before and after updating. It tells you what you are actually fixing and confirms you resolved the reported issues.

Question Every Dependency

Every dependency is another trust relationship. Before adding one, ask: do I need the whole package, or just one function?

Not everything is replaceable. intervention/image or maatwebsite/excel? No. But have you actually thought about it, or did you just composer require by reflex?

Fewer packages means fewer attack surfaces. Fewer broken upgrades when the next Laravel major drops, too.

Check Social Media Before Updating

Follow Laravel security researchers and package maintainers on social media. Major incidents surface there before formal advisories land. The Laravel-Lang attack is a good example.

What Packagist Is Doing

Composer 2.10 integrated Aikido malware detection directly into Packagist. Every release tag now gets scanned automatically.

Stable version immutability is also shipping: once a version is published, it cannot be silently overwritten. One of the tricks in the Laravel-Lang attack was rewriting existing tags to inject malware, making it look like a version you already trusted.

Minimum release age is coming: new releases sit in a quarantine window before they show up in composer update. Security patches wait too. That's the tradeoff. But zero-day injection risk drops.

The long-term plan is a two-step release flow: tag a release, get an MFA confirmation request. A stolen account alone wouldn't be enough to push a release.

Good progress. The ecosystem is large, though, and none of this ships overnight.

TL;DR

Standard practice:

• Commit composer.lock. Always.
• Run composer audit before and after updating.
• Update specific packages when possible, not everything at once.
• Question every new dependency. One class does not need a full package.
• Composer 2.10 added Aikido malware scanning and stable version immutability.

Personal workflow additions:

• Use jack raise-to-installed after every composer update to pin constraints to installed versions. Not standard practice — trades upgrade convenience for narrower exposure on future unexpected jumps. Does not protect against a malicious release you just pulled.
• Verify no package jumped past your PHP version floor after each update.
• Follow Laravel security researchers on social media. Incidents surface there before formal advisories.

Supply chain attacks are no longer a JavaScript-only problem. The Laravel-Lang incident showed that PHP ecosystems are not immune. The workflow above does not guarantee safety. But it reduces the surface you're exposed to on the next update.

References:

• Aikido: Supply Chain Attack Targets Laravel-Lang Packages
• Packagist: Supply Chain Security Update
• Composer 2.10 Release Notes

Author's Note

Thanks for sticking around!
Find me on dev.to, linkedin, or you can check out my work on github.

Laravel, after the happy path.