
Composer 2.11 Adds Dependency Cooldowns
Composer 2.11 adds a config.policy.cooldown setting that delays newly published package versions in hours, days or weeks during dependency resolution. It is opt-in and does not affect existing lockfile installs. Composer uses Packagist's new published-time field (June 2026) instead of publisher-controlled dates to stop backdating bypasses, and it does not auto-exempt security fixes. Users can pass --no-cooldown or set ignore for specific packages. The post compares this to cooldowns in pnpm, Yarn, npm, Bun, Dependabot, Bundler and Cargo.
What it is
Composer 2.11 adds a config.policy.cooldown setting that holds back newly published package versions for a period set in hours, days or weeks. It is off by default. The page does not show the exact config syntax, so check the Composer documentation before writing it into composer.json.
How it works
The cooldown applies during dependency resolution, in composer update and composer require. Existing lockfile installs are not affected.
Composer's older time metadata field can come from a Git commit date or from composer.json, so a publisher can backdate a malicious release past a cooldown. Packagist added a published-time field in June 2026, recording when a version first appeared in the registry. Composer 2.11 reads that field instead. Composer co-founder Nils Adermann said the feature was held up while this metadata was made trustworthy. That is why it missed Composer 2.10.
Preconditions / Affected
- Repositories that lack the published-time metadata cause resolution to fail unless an explicit fallback is configured. This can break private or mirrored repositories after you enable the policy.
- Private Packagist can enforce a cooldown organization-wide, whatever Composer version developers and CI run.
What to do
- Use
--no-cooldownto install an urgent fix immediately. Other security policies stay on. - Use the policy's
ignoresetting to exempt specific packages permanently. - Test the policy against any non-Packagist repositories before rolling it out to CI.
Caveats
- Security fixes are not exempted automatically. The maintainers rejected that because an attacker with publish access could create an advisory, or exploit an existing one, to push a malicious release through.
- Composer stays opt-in, unlike pnpm (24-hour default since version 11) and Yarn, which gate by default. The maintainers debated this because of workflow disruption.
- Other tools mentioned: npm and Bun offer configurable delays, Dependabot has had a three-day default since July 2026, and Bundler added support in June 2026. Cargo's minimum publish age is due to stabilize in Rust 1.100 on 12 November 2026.
Organisations named here
- Socket
Technologies named here
- Composer
- Private Packagist
- Packagist
- pnpm
- Yarn
- npm
- Bun
- Dependabot
- Bundler
- gem.coop
- Cargo
- Rust 1.100
- PHP
- Composer 2.10
- Composer 2.11
- intercom/intercom-php
- Laravel Lang
- pnpm 11
Techniques named here
- Software supply chain attacks
- Dependency cooldown (minimum release age)
- Timestamp backdating
Concepts named here
- intercom/intercom-php
- Laravel Lang
- Nils Adermann
- No automatic security-fix exemption
- Opt-in versus default cooldowns
- Trustworthy release metadata
- Version immutability
Threat actors named here
- intercom/intercom-php compromise (April)
- Laravel Lang attack (May)
Related in Supply Chain


