PHP Supply Chain Attacks Are Rising. Here Is What Composer Actually Catches

In May 2026, attackers compromised eight packages on Packagist, the repository Composer pulls PHP dependencies from, and got malicious code running on machines that installed them. Here is the detail worth knowing if you run a Laravel or PHP project with any frontend build tooling attached. The malicious code was not hidden in composer.json at all. It was hidden inside package.json, the file npm reads, bundled alongside the PHP package specifically to slip past anyone scanning only their Composer files for problems.

I want to walk through what Packagist and Composer have actually built in response to attacks like this one, and where those defenses still leave a gap you need to cover yourself.

What Packagist actually changed

Since March 2026, Packagist.org has been importing malware detection results from a service called Aikido directly into its own platform. When a package version gets flagged, that warning now shows up prominently on the Packagist website itself, and it is also included in the package metadata Composer receives when you install or update something. According to Packagist's own security update post, this detection caught the malicious versions in each of the recent incidents, and the team has been pulling flagged packages within minutes of detection.

What composer audit actually checks, and what it does not

Composer has shipped a built-in audit command since version 2.4, and I think a lot of developers either do not know it exists or assume it covers more than it does.

composer audit

This command checks every package in your composer.lock against Packagist's security advisory database, which is sourced from GitHub Security Advisories and the FriendsOfPHP security advisories repository. If a package version you have installed matches a known, published CVE, this command tells you and exits with a non-zero status, which makes it genuinely useful to drop straight into a CI pipeline.

Here is the limit worth understanding. composer audit checks against known, disclosed vulnerabilities. It does not, on its own, catch a brand new malicious package version the moment it is published, before anyone has written up an advisory for it. That gap is exactly what the newer Aikido-powered malware scanning inside Packagist itself is meant to close, since it looks for malicious behavior patterns rather than waiting for a formal CVE to exist.

The catch: your PHP project probably has a package.json too

This is the part I think deserves more attention than it gets. A huge share of Laravel projects bundle Vite or Mix for frontend asset building, which means a plain composer.json-based PHP project usually has a package.json sitting right next to it. The May 2026 attack specifically exploited exactly this pattern, since the malicious payload triggered through an npm postinstall script, not through anything Composer itself would ever inspect.

If your security review process only ever looks at composer.lock because you think of your project as "a PHP project," you are leaving half your actual dependency tree unchecked. I would run npm audit alongside composer audit as a matching pair, not just one or the other, on any project that has both files present.

What I would actually do about this

Update Composer to the current 2.9.x or 2.10.x release, since both versions added real security improvements over what came before, including automatic security advisory blocking and a new dependency policy framework aimed at filtering malware at install time. Add composer audit to your CI pipeline so it runs on every deploy, not just when you remember to check manually. And if your project has a package.json file anywhere in it, treat that as part of your dependency surface too, since attackers already have.

I would also avoid running a blind composer update right before a deploy without looking at what actually changed. A diff of your composer.lock before and after takes a minute to skim and can catch an unexpected new dependency or a suspicious version jump before it reaches production.

FAQ

Does composer audit require an internet connection?
Yes, it queries Packagist's security advisory API to check your installed versions against known vulnerabilities, so it needs network access to run.

Will composer audit stop a malicious package from installing?
Not by itself. It reports known vulnerabilities after the fact, though Composer's newer versions have started adding blocking behavior for certain flagged packages during install, which is a meaningful step beyond just reporting.

Is this kind of attack unique to PHP?
No. npm, PyPI, and other package ecosystems have all seen similar supply chain incidents. Packagist has actually adopted some of the same staged-release protections that npm introduced earlier in 2026, so the two ecosystems are responding to a shared problem, not an isolated one.

Should I pin exact dependency versions instead of using version ranges?
For anything security sensitive, I would lean toward pinning and deliberately reviewing updates rather than letting a loose version range silently pull in whatever is newest. That trades a little convenience for a real reduction in surprise.

What do I do if composer audit reports a vulnerability I cannot immediately fix?
Check whether a patched version is available and update if so. If the vulnerable package is a hard dependency you cannot change right away, at minimum document the exposure and keep it on your radar rather than letting the audit warning become background noise you learn to ignore.

Bottom line

Composer and Packagist have both added real protections this year, and they are worth using. composer audit catches known vulnerabilities, and Packagist's own malware scanning catches some attacks before an advisory even exists. Neither one covers a package.json file sitting next to your PHP code, though, and that is exactly where the most recent real attack chose to hide.

Sources: Packagist, An update on Composer & Packagist supply chain security; PHP.Watch, New composer audit Command and security audits in Composer 2.4. Verified against official Packagist and Composer documentation on September 7, 2026.