Drupal.org Enables Composer Cooldowns for Over 16,600 Projects

More than 16,600 Drupal projects now have release timestamps available through packages.drupal.org, allowing site operators to use Composer 2.11's optional cooldown policy with Drupal packages. The Drupal Association confirmed the repository change in its October 2026 DA Insider, published on 11 November 2026.

The change allows Drupal teams to delay dependency updates involving newly published package versions, reducing the chance of installing a compromised release before security researchers or automated scanners identify it. The waiting period does not detect malicious packages or guarantee that a compromised release will be identified before it becomes eligible for installation. Site operators must enable the policy themselves because Composer leaves it disabled by default.

Composer 2.11.0, released on 29 October 2026, introduced the cooldown as part of its dependency security policies. It relies on repository-supplied published-time metadata rather than the older time field, which may be based on information controlled by the package author. The distinction matters when an attacker gains access to a legitimate package and attempts to backdate a malicious release. A publication timestamp supplied by the repository provides a more reliable basis for determining a release's age.

Composer requires publication-time metadata for package versions considered under the cooldown policy. When a repository does not provide that information, dependency resolution fails unless an explicit fallback or exemption has been configured. The Drupal Association's confirmation establishes that its repository now supplies the release timestamps needed for the feature across more than 16,600 projects.

Earlier coverage by The DropTimes identified repository-supplied timestamps as a requirement to check when Composer 2.11 entered its release-candidate stage. The Association's November announcement confirms that Drupal.org's package repository supports the metadata needed for the cooldown policy.

Administrators can configure the waiting period under config.policy.cooldown, using values such as six hours or one day. The policy applies during dependency resolution, including composer update and composer require. Running composer install with an existing composer.lock continues to install the locked package versions without reselecting them under the cooldown policy.

Security fixes are also subject to the waiting period. Composer does not automatically exempt releases associated with security advisories because an attacker controlling a package could potentially publish an advisory to bypass such a rule. Administrators can use composer update --no-cooldown vendor/package to bypass the delay for a selected update while retaining Composer's other dependency security policies. Full dependency updates require additional care because they can select older versions when locked packages remain inside the configured cooldown period.

A production implementation was documented on 11 November 2026 by Drupal contributor Jürgen Haas, founder of LakeDrops. In a technical account of the rollout, Jürgen described introducing a one-day cooldown across LakeDrops' managed Drupal projects through centrally maintained Composer configuration. The approach allowed the company to distribute the policy without editing each project's Composer configuration or lock file.

Jürgen reported that the first scheduled update on a LakeDrops demo project withheld five newly published package versions. The company also implemented safeguards to prevent unwanted downgrades, reject replacements of stable releases with development branches, and exempt selected fixes covered by Drupal Security Team advisories. These measures were additions to LakeDrops' own automated update workflow, not protections provided automatically by Composer. Jürgen also reported that publication timestamps for three sampled Drupal releases matched their Drupal.org release creation times within approximately 20 seconds, although the sample does not establish repository-wide accuracy.

The implementation illustrates the trade-offs involved in adopting release cooldowns. Delaying dependency updates can provide time for compromised packages to be identified, but it can also postpone security patches or affect automated dependency resolution. Drupal teams considering the policy need to test its interaction with existing lock files, security-update procedures and private repositories. The repository change makes the option available; the effectiveness and operational consequences depend on how each team configures and manages it.