Composer 2.11 RC1 Adds a Cooldown Against PHP Supply Chain Attacks

PHP's package manager just learned to wait. Composer 2.11.0-RC1, released on October 22, adds a "cooldown" policy that refuses to install package versions until they've been public for a period you choose, giving the ecosystem time to catch a hijacked release before it lands in your vendor/ folder.

Here's what you need to know:

• The new cooldown policy withholds newly released versions during composer update and composer require. It's opt-in: the period defaults to null.

• The clock starts at the publication time Packagist.org records, which package authors can't influence.

• composer install from an existing lock file isn't affected, and dev versions are never held back.

• RC1 also ships four security fixes and removes the source-fallback option, a breaking change.

• Private Packagist can enforce a cooldown across a whole organization, whatever Composer version or project config developers use.

How the new cooldown works: fresh versions wait before Composer will pick them.

What Happened

Composer's maintainers tagged 2.11.0-RC1 on GitHub as a pre-release on October 22. The headline entry in the official changelog is a cooldown policy "to withhold newly released package versions for a configurable period, reducing exposure to compromised releases."

According to Composer's configuration docs, you turn it on in composer.json under config.policy.cooldown.period, using values like "24 hours", "7 days" or "1 week". The docs explain the reasoning plainly: "many malicious versions are identified and removed within hours or days of being published."

The policy also changes what other commands show. composer outdated and composer show --latest report the newest version you're allowed to install and flag any newer release that's still cooling down. Packages you trust can go on an ignore list, with wildcards like mycompany/* and a written reason for each entry.

RC1 isn't only about cooldowns. The changelog lists four security fixes. Composer now rejects TLS connections that present the distrusted eMudhra intermediate certificates. Bin proxies no longer embed package-controlled paths unescaped. secure-http now catches malformed insecure URLs. And custom repository headers no longer leak to look-alike hosts whose names start with the repository's hostname.

There are smaller additions too: composer audit --direct to check only direct dependencies, retries on HTTP 429 responses with Retry-After, a block-scope option so custom policies can also block during install, and an "AI coding agent" marker in Composer's User-Agent.

Why It Matters

The cooldown is a direct answer to a rough year for PHP. In a May 27 update on the Packagist blog, Composer co-creator Nils Adermann and Igor Benko wrote that attackers had hit the PHP ecosystem "via taken-over GitHub accounts and stolen access tokens," publishing new tags on packages they didn't control. They named laravel-lang (May 22) and intercom/intercom-php (April 30) as the most notable cases.

Back then, the same post called a minimum release age "one of the more effective defenses against the recent class of attacks, because malicious versions are typically pulled or detected within hours of publication." It was blocked, though. Packagist first had to make stable versions immutable, so a release's publication time could be trusted as a security signal. The post said stable-version immutability was deploying that same week, alongside Composer 2.10's new dependency policy framework, which the 2.11 cooldown now plugs into.

The stakes are big. The Packagist post says Packagist.org lists more than 469,000 packages, and Composer has installed packages from it more than 200 billion times. One poisoned tag on a popular library can travel far before anyone notices.

PHP teams have had a busy week. We've also covered PHP2Shell, the critical PHP RCE flaws under active attack, which need a PHP update rather than a Composer change.

What It Means for Developers

The feature is a release candidate and off by default, so nothing changes until you opt in. Here's how to put it to work:

• Try the RC. Run composer self-update --preview to switch to the preview channel, ideally in CI or a test project first.

• Set a period. Add "config": {"policy": {"cooldown": {"period": "1 day"}}} to composer.json. Private Packagist's docs suggest that waiting "up to a day" already cuts the risk of installing malware.

• Plan for urgent fixes. Pass --no-cooldown to update, require, remove or create-project for one run, or set COMPOSER_POLICY_COOLDOWN_PERIOD=0. Other policies still apply. Long-term exceptions belong in the ignore list.

• Know the edge cases. A full composer update re-checks every package, so a locked version still inside its cooldown gets swapped for an older release, or the update fails if nothing else fits. Platform packages such as PHP and extensions are never withheld.

• Check private repositories. Composer repositories must provide a published-time for every version, or the command errors out. Repositories that can't provide one can set require-published-time to false and fall back to each package's time field.

• Expect a lock file warning. Once you add a policy config, Composer will flag the lock file as outdated, according to the changelog.

The Composer cooldown settings you need, at a glance.

For teams, Private Packagist's cooldown docs describe an organization-wide setting under Settings > Security. Its security settings guide says held-back versions are left out of the metadata it serves, so the policy works "independent of the Composer version and the project configuration." A "Packages without cooldown" list covers your own packages or urgent security fixes.

Leaked credentials are often what kick off these attacks. Our story on the OpenCode console breach shows how fast stolen keys turn into real damage.

What's Next

Composer hasn't announced a date for the stable 2.11.0 release. RC1 is the time to test the cooldown against real projects and report problems before it ships.

The bigger roadmap is already public. The Packagist blog lists planned work on maintainer MFA visibility in the transparency log, eventually mandatory MFA, FIDO2-backed staged releases for widely used packages, and Packagist-hosted build artifacts with SLSA provenance and Sigstore attestations.

Expect more detail at SymfonyCon Warsaw on November 26-27. PHP News reports that Composer creators Nils Adermann and Jordi Boggiano will give a talk there called "The Attack Reached PHP: Composer and Packagist, One Year On," covering Composer 2.10, 2.11 and where the stack is headed in 2027.

FAQ

Does the Composer cooldown slow down composer install?

No. The cooldown only applies when Composer picks versions, during composer update and composer require. Installing from an existing composer.lock works as before.

Is the cooldown enabled by default in Composer 2.11?

No. The period defaults to null, so the policy only takes effect once you set a duration in composer.json or through the COMPOSER_POLICY_COOLDOWN_PERIOD environment variable.

How do I install an urgent security fix during the cooldown?

Run the command with --no-cooldown for a one-off bypass, or add the package to the cooldown ignore list with a reason. Composer's docs use symfony/security-bundle as an example of a package whose security fixes need to be applied right away.

Sources

• Composer 2.11.0-RC1 changelog, getcomposer.org

• Composer 2.11.0-RC1 release, composer/composer on GitHub

• Config: cooldown policy, Composer documentation

• An update on Composer & Packagist supply chain security, Packagist blog

• Cooldown dependency policy, Private Packagist docs

• Security settings, Private Packagist docs

• Composer After the Attack: A SymfonyCon 2026 Talk, PHP News

Follow TheTechLane

Keep learning AI, development, and modern developer technologies with TheTechLane. Learn • Build • Share Follow @thetechlanehq for more developer guides, tutorials, and practical technology content.