Attacks keep coming. In the past weeks alone, attackers seized GitHub accounts and stolen tokens to push malicious tags on popular PHP packages. The incidents hit hard. Laravel-lang packages saw over 700 historical versions compromised on May 22 and 23, 2026, according to Snyk. Days earlier, intercom/intercom-php fell victim on April 30.
But the response from the maintainers of Composer and Packagist.org shows deliberate progress. Their latest blog post lays out concrete defenses already deployed, features rolling out this week, and longer-term plans that address the root problems of mutable releases and weak maintainer accounts. Packagist blog details it all.
One coordinated campaign in May infected eight packages. The malicious code hid in package.json files rather than composer.json. It targeted projects mixing JavaScript build tools with PHP. “Although the affected packages were all Composer packages, the malicious code was not added to composer.json,” Socket said. “Instead, it was inserted into package.json, targeting projects that ship JavaScript build tooling alongside PHP code.”
The payload downloaded a Linux binary from a GitHub Releases URL, saved it to /tmp/.sshd, made it executable, and ran it in the background. It disabled TLS verification and suppressed errors. “Even without the second-stage binary, the malicious installer is enough to warrant blocking,” Socket added. The eight packages included devdojo/wave, devdojo/genesis, and moritz-sauer-13/silverstripe-cms-theme among others. The Hacker News reported the details on May 23.
These aren’t isolated cases. Attackers exploit the open nature of public repositories. They compromise maintainer credentials. Then they rewrite git tags on existing releases. Users running composer update pull the new, tainted code without realizing the version number stayed the same.
Defenses Already in Place
Packagist integrated malware detection from Aikido in March 2026. Flagged versions now appear prominently on the site and in metadata Composer consumes. The system caught the recent malicious releases quickly.
Incident response happens fast. The small Packagist team pulls compromised packages or versions within minutes. Yet manual work can’t scale. The focus has shifted toward prevention.
A public transparency log records key events. Ownership changes. Maintainer additions and removals. Version reference updates. It proved invaluable in the latest attacks. “The transparency log accurately recorded each of these modifications, which let us identify exactly what had been manipulated and reconstruct precise timelines of each attack,” the Packagist team wrote.
Funded partly by the German Sovereign Tech Agency and organized through the PHP Foundation, the log brings auditability to a repository handling over 400,000 packages and 100 million daily installs. Anyone can review history for a package. See when tags changed. Spot sudden maintainer swaps. The log requires login today but offers a foundation for broader monitoring tools.
And the pressure on maintainers grows. If you maintain packages on Packagist.org and haven’t enabled multi-factor authentication, do it now. MFA status will soon appear in the transparency log and on public profiles. The change turns account security from private practice into visible package property. Downstream users gain information they currently lack.
New Protections Shipping Immediately
Composer 2.10 arrives this week. It introduces a unified dependency policy framework. The single system handles malware flags, vulnerability advisories, and abandoned packages. Future rules fit cleanly inside it.
One planned follow-up blocks releases younger than a set age. Such cooldown periods stop fresh malicious versions before detection catches up. The policy depends on immutable metadata first.
That immutability lands now. Stable tagged versions on Packagist.org can no longer be silently rewritten by upstream git tag changes. Packagist will reject re-tags on non-dev versions and notify maintainers by email. Dev branches tied to mutable references continue unchanged.
The decision enforces a practice long recommended. Never rewrite a released version. Fix problems with new releases instead. The consequences of mutation run deeper than many realize. Mirrors and SBOM tools copy metadata instantly. Lock files offer partial protection but break on updates. Account takeovers become far more dangerous when attackers can backdoor existing popular versions.
Composer itself adjusts behavior too. It aims to deliver the originally published artifact or fail clearly. No more silent swaps.
Additional admin tools are coming. Manual overrides for malware feeds. Delisting for older Composer clients. Package freezing during active repository compromises. These changes reduce friction during live incidents.
Private Packagist gains new organization-level controls. Details follow in coming days. The broader roadmap points toward mandatory MFA, FIDO2-backed staged releases for high-impact packages, and eventual hosting of immutable build artifacts with SLSA provenance and Sigstore attestations verified client-side.
The team participates in the OpenSSF Securing Software Repositories Working Group. Their goals align with Level 3 authorization principles and advancing dependency track standards.
PHP developers face real exposure. Many projects still run outdated Composer versions. They skip lock file reviews. They allow source fallbacks that Composer 2.10 will deprecate. The recent Perforce driver command injection flaws fixed in April, tracked as CVE-2026-40261 and CVE-2026-40176, reminded everyone that even the dependency manager itself carries risks. Packagist announced those patches in mid-April.
Yet the ecosystem shows signs of hardening. Transparency creates accountability. Immutability removes a favorite attacker technique. Policies give operators granular control. Detection feeds surface threats early.
Still, no single change solves everything. Attackers adapt. They target popular packages with many transitive dependents. They use cross-language tricks like the package.json hooks. They hunt for abandoned but still-downloaded libraries.
Organizations should audit dependencies now. Review composer.lock files for unexpected commits. Enable MFA everywhere. Consider private repositories for critical internal packages. Monitor the transparency log for packages they rely on. And update Composer immediately to 2.10 or the latest 2.2 LTS.
The Packagist team has spent close to a year focused on these issues. Their pace is measured. Each step builds on the last. The transparency log already delivered value in active incidents. Version immutability closes a longstanding gap. Dependency policies create a flexible foundation for future defenses.
PHP powers a huge slice of the web. Its package supply chain must match that importance. The recent attacks exposed weaknesses. The responses underway demonstrate serious commitment to closing them. Progress continues. But vigilance from every maintainer and user remains essential. Check your dependencies today. The next compromise may already be in progress.
WebProNews is an iEntry Publication