Composerのロックファイルからコマンド実行のおそれ｜2.11.2更新とCI入力の点検

Composerの開発元は2026年11月10日、ロックファイルを介したコマンド実行、ZIP展開先の逸脱、リポジトリ認証情報の漏えいに関する3件の勧告を公開しました。PHPアプリケーションの依存ライブラリーだけでなく、依存関係を取得するComposer本体が更新対象です。通常系列は2.11.2、2.2 LTS系列は該当する問題に対して2.2.32を確認します。

特に、第三者が変更したcomposer.lockをCIで処理する環境は優先して点検してください。コマンド実行の問題は、パッケージのスクリプトやプラグインを無効にしても防げません。アプリケーションのコードレビューだけでは見落とす、依存関係の記録ファイルと取得処理の境界が今回の焦点です。

本稿は11月11日に取得した開発元の勧告と変更履歴に基づく脆弱性ニュースです。以下の運用手順は本サイトの提案であり、攻撃を実行して動作を実測したものではありません。3件の勧告には確認時点でCVE番号がなく、実環境での悪用確認の記載もありません。

まずComposerの実行版と入力元を組にする

端末で使うComposerと、CIやコンテナで使うComposerが同じとは限りません。最初に、依存関係を取得するジョブ、実行ファイルの配置場所、起動版、取得するリポジトリ、使う認証情報を対応付けます。Webサーバー上でComposerを実行していなければ、そのサーバーのPHP版だけを調べても今回の影響判断は終わりません。

通常系列の2.10.0以上2.11.2未満では、ロックファイル等から読み込むコールバック設定の問題があります。一方、2.2 LTS系列はこのコマンド実行には該当しません。ただし、LTS利用者もZIP展開と認証情報漏えいの問題を別に判断する必要があります。「LTSだから3件とも対象外」とまとめないことが重要です。

ロックファイルからコマンドが実行される条件

開発元のコマンド実行に関する勧告は、composer.lockまたはvendor/composer/installed.jsonへ攻撃者が影響を与えられ、その内容に対してinstallやupdateを実行する構成を対象としています。transport-options.prevent_url_access_callableがデータファイルから取り込まれ、ダウンロードの解決時にコマンドが実行され得ます。

開発元は、未審査のプルリクエスト、外部テンプレート、侵害された依存関係更新Bot、汚染されたCIキャッシュを具体例に挙げています。悪性パッケージのインストールやパッケージ内コードの起動を待たず、チェックサム等の整合性検証より前に実行される点が、通常の依存パッケージの危険性とは異なります。

2.11.2の修正は、ロックファイルやインストール済み情報から来たダウンロード時コールバックを無視し、プログラムで設定したものだけを扱う変更です。勧告は--no-scriptsと--no-pluginsでは防げないと明記しています。これらの指定がCIにあることだけを理由に、未審査ファイルを安全に処理できるとは判断しないでください。

開発元評価はCVSS v3.1で8.8、Highです。この値はGHSA-jhfp-4ppm-crmmの評価として扱い、他の2件やプロジェクト全体の危険度へ流用しません。第三者が入力ファイルを操作できる経路と、Composerを実行する必要があり、公開Webサイトへ任意のHTTP要求を送るだけで成立する問題と同一視しないようにします。

ZIPは展開先とフォールバックを確認する

ZIP展開の公式勧告は、シンボリックリンクを含む細工されたアーカイブで、想定するパッケージディレクトリ外へファイルを書き込める問題です。unzipからPHPのZipArchiveへ処理が切り替わる経路に関係します。修正版は2.11.2と2.2.32です。

成立条件には、攻撃者が配布ZIPを制御できること、実行環境にunzipコマンドとPHPのZIP拡張があることが挙げられています。通常のPackagist.org由来のアーカイブのみを使う構成は、開発元が示す現実的な攻撃経路ではありません。非信頼のリポジトリ、独自ホスト、ミラーや任意のdist URLを使う場合を重点的に確認します。

この問題の直接の作用は任意ファイル書き込みです。Webアプリの入口など、後から実行される場所が上書きされればコード実行へつながり得ますが、すべてのZIPで即座にコマンドが動くという説明ではありません。配置先への書き込み権限と、生成物を本番へ渡す工程まで含めて影響を考えます。

インラインHTTPヘッダーの秘密情報を点検する

認証情報漏えいの公式勧告の対象版は2.11.0、2.11.1、2.2.31です。リポジトリのオプションにAuthorizationやAPIキーなどの秘密をHTTPヘッダーとして直接設定し、攻撃者がロックファイル等を改変できる場合、取得ミラーを攻撃者のホストへ向けて認証情報を送信させる可能性があります。

こちらは当該リポジトリの認証情報の漏えいであり、それ自体によるコード実行やファイル変更ではありません。インラインの秘密ヘッダーを使わない構成は、勧告が示す条件に該当しません。修正版への更新に加え、自組織がどの方式で認証情報を渡しているかを確かめ、秘密の実値をログへ出さずに設定箇所と利用先を把握します。

更新はライブラリーではなくツール本体へ行う

Composer 2.11.2の公式変更履歴は11月11日公開として表示されています。勧告の11月10日という日付と、変更履歴の日付を分けて記録してください。通常系列の更新先は2.11.2、2.2 LTSを維持する構成では2.2.32です。

まずcomposer --versionで実行版を記録します。自己更新で管理している実体なら、通常系列の例はcomposer self-update 2.11.2です。LTSならcomposer self-update 2.2.32を使う判断になります。OSパッケージ、コンテナイメージ、CIセットアップ処理が管理する場合は、その配布元の更新手順を使い、同じファイルを複数の方式で上書き管理しないようにします。

プロジェクト内でcomposer updateを実行するだけでは、Composer本体の更新にはなりません。逆に今回の対応を名目として依存パッケージを一斉更新すると、アプリケーションの差分とツール修正の差分が混ざります。まず本体の更新と実行版の確認を行い、依存関係を変更する必要があるかは別の作業として判断します。

イメージにComposerを組み込む場合は、Dockerfileや取得スクリプトが固定する版、ビルドキャッシュ、実際に起動するジョブのイメージを照合します。共有Runnerのホスト側だけを更新しても、ジョブ内のコンテナが別のComposerを持っていれば適用されません。実行環境の内側で版を確認した結果を、ジョブ識別子とともに記録します。

更新前の停止判断と更新後の確認を分ける

修正版を導入するまでの提案として、未審査のロックファイルを秘密情報付きの強い権限で処理するジョブは保留します。確認対象のファイルを開くレビューと、その内容で依存関係を取得する処理を区別してください。単にPRのテストが必要という理由で、本番の配布トークンまで渡す必要はありません。

更新後は信頼できる既存の入力で依存関係の取得を試し、起動版、依存パッケージの取得先、認証失敗、展開失敗を確認します。攻撃用ZIPやコマンドを本番で実行して脆弱性の再現を確認する必要はありません。通常業務の取得とビルドが成功することと、修正版が使われていることを別々に証拠として残します。

取得が失敗した場合は、本体が更新されたか、ミラーのURLや認証方式が意図どおりか、ZIP処理でどの実装が使われたかを順に確認します。エラー回避のために古いComposerへ無期限に固定したり、非信頼の配布物を別経路で取得したりすると、対策の前提が失われます。まず限定した検証環境で必要な構成差を調べます。

CIキャッシュは性能設定としてだけ扱わず、入力ファイルを誰が書き込めるかを確認します。非信頼ブランチが作ったキャッシュを、秘密情報を持つジョブが復元する構成は、PRそのもののレビューとは別の入力経路になります。キャッシュキー、書き込み元、復元先を対応付け、疑わしいキャッシュは保全と利用停止の手順を決めます。

過去に処理したファイルと認証情報の調査

更新は今後の処理を修正するもので、過去の不審な実行や漏えいがなかったことを証明しません。第三者が変更したロックファイルを対象版で処理した疑いがある場合は、入力のコミット、ジョブの実行時間、キャッシュ、生成物、外向き通信を保全し、調査対象の実行環境を特定することを提案します。

リポジトリの秘密ヘッダーを使う環境では、その資格情報の権限と利用履歴も確認します。すべての秘密を一律に交換するという意味ではなく、不審な取得先へ送信された可能性がある情報を絞るためです。失効や再発行が必要なら、利用するジョブやサービスへの差し替えと、旧トークンが使えないことの確認を組にします。

今回の3件は入力経路と結果が異なります。コマンド実行、ファイル書き込み、認証情報送信を一つの検知条件で済ませず、使っていた版と処理内容に応じて調査範囲を決めてください。公式資料に悪用確認の記載がないことは、自組織の被害がない証拠ではありません。異常が見つかれば、通常の更新完了とは分けて対応します。

最終的な完了条件は、対象となるComposer実体が修正版になり、再実行したジョブがその版を使い、必要な取得とビルドが成功することです。ロックファイルのレビュー、CI入力の分離、トークンの権限制限は、修正版の適用と並行して維持する防御になります。