Packagist Makes Stable Package Versions Immutable to Protect PHP Supply Chains

Almost every modern PHP application, whether it is built on Laravel, Symfony or another framework, is assembled from dozens or hundreds of open source packages. Those packages are downloaded through Composer, the PHP dependency manager, from Packagist.org, the public package registry. On July 7, 2026, Packagist announced a change to how that registry treats published releases: stable versions are now immutable.

That sounds like an internal detail, but it closes a gap attackers have used against software supply chains. If your business runs a custom PHP application, or you are commissioning one from a Laravel development team, this change makes the code your application depends on more predictable, and it comes alongside related changes in Composer that your developers should act on.

What Packagist announced on July 7, 2026

In its post Immutable Versions on Packagist, written by Nils Adermann, Packagist states that once a stable version has been published on Packagist.org, the point in the source code history that it refers to never changes. A release labelled 3.9.0 will always mean the same code it meant on the day it was published.

Before this change, a package maintainer, or anyone who had obtained the maintainer's access, could delete a release tag in the source repository and recreate it pointing at different code. The registry would then follow along. According to the announcement, Packagist.org now detects that situation, blocks the change, keeps the original reference, shows a warning on the package page and emails the maintainers.

The post describes this as in effect now on Packagist.org. Development versions that follow a branch are not affected, because a branch is expected to move.

Why changing a published version is a problem

The announcement gives two reasons. The first is accidental. A maintainer publishes a release, notices a mistake minutes later, and re-creates the tag. The result, in Packagist's words, is two different variants of the same version number in circulation, which are extremely hard to tell apart. Two teams can believe they are running the same version and not be.

The second reason is security. The post explains that someone who gains push access to a repository, through a compromised maintainer account or a stolen token, can move an existing, trusted, widely installed tag onto malicious code. Packagist notes that this is the same route behind several recent incidents in the PHP ecosystem. An earlier supply chain security update published on May 27, 2026 names two of them: a credential stealer distributed through the laravel-lang packages on May 22, 2026 after a GitHub account was compromised, and a malicious intercom/intercom-php release on April 30, 2026 that followed stolen access tokens.

Immutability matters because every safeguard built around version numbers assumes they are stable. Security reviews, vulnerability advisories, malware scans and internal approved-package lists all refer to a package by name and version. If the code behind that version can change, those checks lose their meaning.

What happens to deleted versions

The announcement also changes how removal works. Instead of versions vanishing, Packagist now uses soft-deletion: a removed version stays visible with a label explaining why, for example that it is no longer found in the source repository, was deleted by the maintainer or was removed by an administrator. Depending on the reason, the maintainer or an administrator can restore it.

Deletions, recoveries and blocked changes are recorded in a transparency log for the package, according to the post. For a business, the value is an audit trail. If a dependency behaves unexpectedly, there is a record of what changed and when.

How this fits with Composer 2.10

Immutable versions are one part of a wider program. On May 28, 2026, the project published the Composer 2.10 release, which the announcement says adds built-in malware filtering based on data from the security company Aikido. Versions flagged as malware are removed from the set Composer will consider when updating or adding packages, and the check also runs when installing from an existing lock file, which is the step that normally happens during deployment.

Composer 2.10 also introduces a single policy setting that governs how a project treats malware, known security advisories and abandoned packages. By default, per the release post, malware blocks both updates and installations, security advisories block updates, and abandoned packages are only reported.

One item is announced rather than complete. Composer 2.10 deprecates the old behavior of falling back to a source download when a package archive cannot be fetched, and the post says it will be removed in Composer 2.11. No date for 2.11 is given.

What is still planned

It is important not to overstate what is in place. The July 7 announcement covers the version reference held in the registry. Packagist says its next goal is immutable artifacts, meaning the downloadable archive of each version, which it intends to deliver in the next months through a mix of hosting artifacts itself and publishing verification information in the transparency log. That is a stated intention without a fixed date.

The May 27 update lists further work in progress, including making multi-factor authentication status visible and moving toward requiring it for maintainers, and a minimum release age option that would let projects refuse versions published only hours earlier. These are described as in progress or longer-term, so they should not be assumed to be available today.

What this means for your business

The following is guidance, not a statement from Packagist. For most companies, nothing breaks and nothing needs to change on the day. The announcement says existing lock files are unaffected, since versions keep the references they already had. The benefit arrives quietly: one route for tampering with code you already trust has been closed at the registry.

It does not make dependencies safe by default. A compromised maintainer can still publish a new malicious version, which is why the malware filtering in Composer 2.10 and disciplined update habits matter. Immutability ensures that a version your team reviewed last month is still the same code today. It does not review the next version for you.

This is also a useful prompt for a conversation with whoever maintains your software. How a supplier manages third-party code is a reasonable topic to raise, whether you are based in the US or the UK, when you outsource software development.

What to do next

• Ask which Composer version your build and deployment systems use, and plan a move to 2.10 or later so malware filtering applies during installs.
• Confirm that the lock file is committed to version control and that deployments install from it, so production gets exactly the versions that were tested.
• Check whether any part of your pipeline relies on source fallback downloads, since that behavior is deprecated and scheduled for removal in Composer 2.11.
• If your team publishes its own packages on Packagist.org, stop re-creating release tags. Packagist's advice is to publish the fix as the next version.

It is also worth agreeing how security advisories are handled: who sees the Composer audit output, and how quickly a flagged dependency is updated.

Conclusion

Since the announcement of July 7, 2026, a stable version on Packagist.org always points to the same code, and attempts to rewrite it are blocked and logged. Together with the malware filtering introduced in Composer 2.10 on May 28, 2026, this makes it harder to slip altered code into PHP applications through packages they already use. Immutable download artifacts and stronger maintainer authentication are planned but not yet delivered.

If you would like a review of how your PHP application manages its dependencies and deployments, contact Entrant Technologies to talk it through.