Composer 2.11 Is Out: Cooldown Periods Against Hijacked Packages, Six Security Fixes, and No More Source Fallback

Composer 2.11.0 is out, announced on 29 October 2026 by Nils Adermann on the Packagist blog. The final release follows the 2.11.0-RC1 we covered earlier, and its headline feature is the cooldown dependency policy, which withholds newly published package versions for a period you choose before Composer will install them. It also ships six security fixes and removes the dist-to-source fallback deprecated in 2.10.

Why a cooldown period

According to the announcement, most malicious releases seen on Packagist.org in recent months came from attackers who briefly took control of a legitimate package, for example through a compromised GitHub account. Composer 2.10's malware policy blocks such versions once they are flagged, but there is always a window between publication and flagging. A cooldown period narrows that window: even an hour gives automated scanners a chance, and a few hours to a day gives manual reports time too.

The policy is off by default. To withhold anything published in the last day:

{
    "config": {
        "policy": {
            "cooldown": {
                "period": "1 day"
            }
        }
    }
}

You can also set it globally or with the COMPOSER_POLICY_COOLDOWN_PERIOD environment variable, which is handy in CI. Some details worth knowing:

• It applies when Composer resolves dependencies (update, require). composer install still installs exactly what is in composer.lock.
• dev-main-style dev versions and platform packages are never withheld.
• A full composer update re-evaluates everything, so a locked version still inside its cooldown can be replaced with an older one.
• The cooldown relies on a new published-time that Packagist.org records itself, because the old time field is controlled by the publisher and could be backdated. If another repository doesn't report published-time, the command fails and names the package rather than silently skipping the check.

Security fixes are delayed too

The cooldown applies to every new version, including security releases. Composer deliberately does not exempt releases based on advisory data, since an attacker with repository access could publish a fake advisory. To pull a fix immediately, use the new --no-cooldown option, which skips only the cooldown and keeps advisory and malware blocking active:

composer update --no-cooldown vendor/package

Packages you always trust, such as your own, can be exempted with an ignore list that supports wildcards like mycompany/*.

Six security fixes

Composer 2.11 itself fixes:

• Package names in vendor/composer/installed.json can no longer escape the vendor directory during install and reinstall (GHSA-c968-33g3-wh7p).
• HTTP headers configured inline in a repository config, such as API tokens, are no longer written into composer.lock or installed.json (GHSA-fm2w-xgf2-f9fh).
• TLS connections presenting the distrusted, compromised eMudhra intermediate certificates are rejected even if the system CA store trusts their roots.
• Bin proxies no longer embed package-controlled bin paths and shebangs unescaped, and bin paths with shell metacharacters are rejected.
• secure-http now also catches insecure URLs that are not strictly valid or use git's :: syntax.
• Custom repository headers are no longer sent to dist URLs on other hosts whose name merely starts with the same string as the repository host.

The header leak is worth a look on older projects: if you ever put a token inline in a repository config, check whether it ended up in a committed lock file and rotate it if so.

Breaking change: no more source fallback

When a dist download fails, Composer 2.11 no longer falls back to a source checkout, and the temporary source-fallback option from 2.10 is gone. If you rely on source installs, set preferred-install or use --prefer-source explicitly. Also expect a lock file warning after upgrading if your project defines a policy config, because Composer now treats policy changes as making the lock file outdated.

Other improvements

Dependency resolution is faster and uses less memory, Composer no longer requests HTTP/3 (which added a delay to each new connection with recent curl), composer outdated loads metadata in parallel, composer audit --direct audits only direct dependencies, and Composer now retries on HTTP 429 with Retry-After. Custom policies can also block during composer install with block-scope.

Upgrade with composer self-update.

Older projects

Teams on old PHP versions often pin an old Composer too, and miss these supply-chain protections entirely. If your application is stuck on legacy PHP and can't easily run a current Composer, RescuePHP can help you upgrade the toolchain and PHP version step by step, or backport fixes where an upgrade isn't possible yet.