Composer 2.11 正式リリース：乗っ取られたパッケージ対策のクールダウン期間、6件のセキュリティ修正、ソースへのフォールバック廃止

Composer 2.11.0 がリリースされました。2026年10月29日に Nils Adermann 氏が Packagist ブログで発表しています。以前お伝えした 2.11.0-RC1 に続く正式版で、目玉機能はクールダウン依存ポリシーです。新しく公開されたパッケージバージョンを、指定した期間が過ぎるまでインストール対象から外します。あわせて6件のセキュリティ修正が含まれ、2.10 で非推奨になった dist からソースへのフォールバックが削除されました。

なぜクールダウン期間なのか

発表によると、ここ数か月に Packagist.org で見つかった悪意あるリリースの多くは、侵害された GitHub アカウントなどを通じて正規パッケージを一時的に乗っ取った攻撃者によるものでした。Composer 2.10 のマルウェアポリシーは、フラグが付いたバージョンをブロックしますが、公開からフラグ付けまでには必ず時間差があります。クールダウン期間はその隙間を狭めます。1時間でも自動スキャナーが検知する余地が生まれ、数時間から1日あれば手動での報告にも時間を与えられます。

このポリシーはデフォルトでは無効です。直近1日以内に公開されたバージョンを保留するには次のように設定します。

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

グローバル設定や、CI で便利な COMPOSER_POLICY_COOLDOWN_PERIOD 環境変数でも指定できます。知っておきたい点は次のとおりです。

• 適用されるのは依存関係を解決するとき（update、require）です。composer install はこれまでどおり composer.lock の内容をそのままインストールします。
• dev-main のような開発版とプラットフォームパッケージは保留されません。
• composer update を全体に対して実行するとすべてが再評価されるため、ロック済みのバージョンがクールダウン期間内なら、より古いバージョンに置き換わることがあります。
• クールダウンは、Packagist.org 自身が記録する新しい published-time に基づきます。従来の time フィールドは公開者が操作でき、日付をさかのぼらせることが可能だったためです。別のリポジトリが published-time を返さない場合、チェックを黙って飛ばすのではなく、コマンドが失敗して該当パッケージ名を表示します。

セキュリティ修正も遅れる

クールダウンはセキュリティリリースを含むすべての新バージョンに適用されます。リポジトリにアクセスできる攻撃者が偽のアドバイザリを公開できてしまうため、Composer はアドバイザリ情報を根拠に自動で除外することをあえてしていません。修正をすぐに取り込みたい場合は新しい --no-cooldown オプションを使います。スキップされるのはクールダウンだけで、アドバイザリやマルウェアによるブロックは有効なままです。

composer update --no-cooldown vendor/package

自社パッケージなど常に信頼するものは、mycompany/* のようなワイルドカードに対応した ignore リストで除外できます。

6件のセキュリティ修正

Composer 2.11 自体の修正内容は次のとおりです。

• vendor/composer/installed.json 内のパッケージ名が、インストールや再インストール時に vendor ディレクトリの外へ抜け出せなくなりました（GHSA-c968-33g3-wh7p）。
• API トークンなど、リポジトリ設定にインラインで書いた HTTP ヘッダーが composer.lock や installed.json に書き込まれなくなりました（GHSA-fm2w-xgf2-f9fh）。
• 信頼が取り消された、侵害済みの eMudhra 中間証明書を提示する TLS 接続は、システムの CA ストアがルートを信頼していても拒否されます。
• bin プロキシが、パッケージ側で制御できる bin パスや shebang をエスケープせずに埋め込むことがなくなり、シェルのメタ文字を含む bin パスは拒否されます。
• secure-http が、厳密には不正な形式の URL や git の :: 構文を使った安全でない URL も検出するようになりました。
• リポジトリのホスト名と先頭が同じ文字列で始まるだけの別ホストの dist URL に、カスタムヘッダーが送られなくなりました。

ヘッダー漏えいの件は古いプロジェクトで確認する価値があります。リポジトリ設定にトークンを直接書いたことがあるなら、コミット済みのロックファイルに入っていないか確認し、入っていればトークンを再発行してください。

破壊的変更：ソースへのフォールバック廃止

Composer 2.11 では、dist のダウンロードに失敗してもソースのチェックアウトにフォールバックしなくなり、2.10 の一時的な source-fallback オプションも削除されました。ソースからのインストールが必要なら、preferred-install を設定するか --prefer-source を明示的に使ってください。また、プロジェクトに policy 設定がある場合、ポリシーの変更でロックファイルが古いと判定されるようになったため、アップグレード後にロックファイルの警告が表示されます。

その他の改善

依存関係の解決が高速化してメモリ使用量も減りました。最近の curl で新規接続ごとに遅延が生じていた HTTP/3 の要求をやめ、composer outdated はメタデータを並列で読み込み、composer audit --direct で直接の依存関係だけを監査できます。HTTP 429 と Retry-After を受けた場合は待ってから再試行します。カスタムポリシーも block-scope で composer install 時にブロックできるようになりました。

アップグレードは composer self-update で行えます。

古いプロジェクトでは

古い PHP を使い続けているチームは Composer も古いバージョンに固定していることが多く、こうしたサプライチェーン対策をまったく受けられていません。レガシー PHP から抜け出せず最新の Composer を動かせない場合は、RescuePHP がツールチェーンと PHP バージョンの段階的なアップグレードを、またすぐに移行できない場合は修正のバックポートをお手伝いします。