The past few weeks have shown how vulnerable the PHP ecosystem is to attacks on the software supply chain, too. For a long time, supply chain security was considered primarily an NPM problem. Anyone who followed the recent incidents involving laravel-lang (May 22) and intercom/intercom-php (April 30) knows: PHP is no less affected — we just tend to have it on our radar less often.
In both cases, attackers used compromised GitHub accounts or stolen access tokens to publish malicious Git tags on packages they had no legitimate access to. The result: malicious code in widely used packages, landing on thousands of systems during a composer update.
The Packagist team has now explained in a detailed blog post what is already active, what is shipping this week, and where things are heading in the long term. The roadmap is impressive — and shows that consistent work on the infrastructure has been underway for almost a year.
What Already Works
Since March 2026, Aikido malware detection has been integrated directly into Packagist.org. When a version is flagged as malicious, that appears both in the Packagist UI and in the metadata Composer retrieves. In the recent incidents, Aikido correctly flagged the compromised versions.
Alongside this, there is already a public transparency log on Packagist.org. This log records security-relevant events: ownership transfers, maintainer changes, version reference changes. During the current attacks — in which attackers manipulated existing Git tags after the fact — the log documented exactly what was changed. That is solid forensic infrastructure.
What Is Coming This Week: Composer 2.10
This is the part that interests me most — and creates an immediate need for action.
Immutability of stable versions is the most important change. Until now, an attacker (or a careless maintainer) could simply move an existing Git tag — and Packagist silently updated the reference. That is over. With this deployment, stable versions can no longer be silently overwritten. Tag changes in the upstream repository are detected and rejected; the maintainer receives an email notification.
That sounds like a minor detail, but it is not. Mutable releases mean that a compromised account can add a backdoor to a trusted version that has already been installed millions of times. Anyone running composer update then gets the manipulated code, without a warning, without a version number change. This attack surface is now being closed.
Composer 2.10 also introduces a unified Dependency Policy Framework. Malware flags, security warnings, and abandoned packages are managed through a shared, configurable mechanism rather than being stacked on top of one another as individual features. That is the right architectural decision because it creates a clear extension point for future policies.
The source fallback is being deprecated and will be removed entirely in version 2.11. Until now, Composer could fall back to the Git repository as a source if a dist download failed. That behavior could lead to unexpected code downloads in certain attack scenarios. Good that it is going away.
What Comes Next: Cooldown Periods and MFA Visibility
Two planned features I consider particularly effective:
Minimum Release Age: A policy that prevents brand-new releases from being installed immediately in CI/CD pipelines. Most malicious versions slipped into packages are discovered and removed within hours. Enforcing a cooldown of, for example, 24 hours takes away the attackers' crucial window of opportunity. This policy depends directly on the version immutability described above — which is why it has not arrived yet, but will soon.
MFA status becomes publicly visible: In the future, maintainers' MFA status will appear on their profiles and in the transparency log. That creates social pressure, which I consider an effective lever. If you maintain a widely used package without 2FA, you will notice.
What Made Me Take Action Today
I maintain several packages on Packagist.org, including n98-magerun2. Today I secured my Packagist account with 2FA. Honestly, I had not even thought about it. But better late than never.
Not because someone forced me to. But because reading the Packagist blog post made me realize: this is no longer a hypothetical threat. The incidents are real, the attack vectors are documented, and the consequences of a compromised account affect not just me — but everyone who uses the tool.
Anyone who is not yet using a good password manager should change that anyway. Tools such as 1Password, Bitwarden, and KeePassXC all support TOTP-based 2FA directly today — no separate authenticator app chaos required. A password manager that covers 2FA lowers the barrier to enabling it to almost zero. There is no reasonable excuse anymore.
Trust is a currency. If you maintain a widely used open-source package, you share responsibility for the security of the systems it runs on. You cannot pass that on to someone else. Not to Packagist, not to Composer, not to GitHub.
What I Recommend to Every Maintainer
-
Enable 2FA on Packagist.org — now. MFA status will soon be publicly visible. Those who act now do so out of conviction, not pressure.
-
Update Composer to 2.10 as soon as the version is released. The source fallback behavior alone is a good reason.
-
Do not use shared company accounts for packages. The Packagist team is currently building Organizational Package Ownership to make this transition easier.
-
Know the transparency log. Anyone maintaining or using packages should know that changes are recorded there — and when MFA events will be recorded as well.
Putting It in Perspective: An Ecosystem Tightens the Screws
NPM introduced mandatory 2FA for popular packages earlier, and PyPI made it mandatory for all maintainers in January 2024. The Packagist team itself says Composer is lagging behind in some areas — but the roadmap now announced is not an ad hoc reaction. Version immutability, a Dependency Policy Framework, FIDO2-backed release flows, SLSA provenance — this is clearly work planned over months. The Sovereign Tech Agency co-funded parts of it, which shows that critical open-source infrastructure is now considered worth protecting.
Incidentally, AI has added momentum in both directions here. Automated analysis helps detect anomalies — but it also lowers the barrier for attackers to create convincing malicious commits. The arms race is real.
What remains for us as a community: do our part. And that starts with enabling 2FA. It takes five minutes.