PHP2Shell：PHP の重大な脆弱性と、再現可能なビルドの重要性

2026年10月21日、PHP プロジェクトは、認証されていない攻撃者によるリモートコード実行につながる可能性がある、2件の重大な脆弱性を修正するセキュリティ更新を公開しました。

対象は、PHP2Shell と呼ばれる CVE-2026-109618 と CVE-2026-109619 です。いずれも CVSS v4.0 の深刻度スコアは 9.2 とされています。GitHub

10月26日には、米国のサイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）が、両脆弱性を「悪用が確認された脆弱性カタログ（KEV）」に追加しました。日本の情報処理推進機構（IPA）も10月27日にこの情報を追記し、対策済みバージョンへの移行を改めて呼びかけています。すでに実際の攻撃で悪用されている脆弱性として、対応が必要です。IPA 独立行政法人 情報処理推進機構

PHP アプリケーションを運用するチームにとって、最優先は適切な修正の適用です。ただし、緊急の更新では、ビルドに関する別の問題も表面化します。同じアプリケーションを再ビルドしても、以前と同じ環境になるとは限らないという問題です。

Docker イメージのタグが指す内容が変わっている。OS のパッケージリポジトリから、以前より新しいパッケージが取得される。初回のデプロイ時には利用できた依存関係が、すでに取得できなくなっている。

こうした変化が重なると、以前のビルドと修正後の環境で、何が変わったのかを特定しにくくなります。セキュリティ更新においても、再現可能なビルドと、依存関係を継続して取得できる仕組みが重要になる理由です。

PHP2Shell とは何か

PHP2Shell は、PHP がリクエストを処理する際のメモリ管理に関わる、2件の脆弱性を指します。

CVE-2026-109618 は、メモリの割り当てに失敗したときのエラー処理に起因します。特定の条件下で、初期化が完了していないデータをリクエスト終了時の処理が参照し、メモリ破損につながる可能性があります。GitHub

CVE-2026-109619 は、リクエストに関連する内部状態が、その状態を格納していたメモリの解放後も残る問題です。後続の処理が、その無効になったメモリ参照を使う可能性があります。GitHub

いずれも、特定のアプリケーションのコードではなく、PHP ランタイム自体の脆弱性です。PHP のバージョンや実行環境の構成によっては、攻撃者が PHP プロセスの権限で任意のコードを実行できる可能性があります。

PHP プロジェクトは、Apache の mod_php や PHP-FPM など、ウェブリクエストを処理する PHP 環境を対象として注意を呼びかけています。アプリケーションの依存ライブラリだけでなく、インフラ全体で使われている PHP のバージョンや、ベンダーが提供する PHP パッケージの修正状況を確認する必要があります。2026

修正が提供された PHP のバージョン

PHP プロジェクトは2026年10月21日、サポート対象の4系列に対して修正版を公開しました。

PHP の系列	今回の修正を含む最初のリリース
PHP 8.2	8.2.35
PHP 8.3	8.3.36
PHP 8.4	8.4.27
PHP 8.5	8.5.12

影響を受ける PHP 公式リリースを利用している場合は、該当する修正版、またはそれ以降のサポート対象バージョンへ更新してください。IPA 独立行政法人 情報処理推進機構

Linux ディストリビューションでは、提供中の PHP パッケージに修正をバックポートする場合があります。そのため、表示される PHP のバージョン番号が古いという理由だけで、未修正とは判断できません。OS ベンダーのセキュリティ情報で、インストール済みのパッケージに修正が含まれているかを確認してください。延長サポートやベンダーによる保守を利用している旧系列についても、同様の確認が必要です。2026

まずは PHP のセキュリティ更新を進めます。そのうえで、再ビルド時に PHP 以外の何が変わったかも確認しておくと、更新後にアプリケーションの動作が変わった場合の調査に役立ちます。

同じ Dockerfile でも、ビルド結果が変わる理由

Ubuntu のパッケージリポジトリから PHP をインストールする、次の Dockerfile を考えてみます。

FROM ubuntu:24.04

RUN apt-get update && \
    apt-get install -y php-cli

この Dockerfile では、Ubuntu のリリースとインストールするパッケージを指定しています。しかし、PHP パッケージの正確なバージョンや、パッケージマネージャが解決するすべての依存関係までは指定していません。

apt-get update を実行すると、その時点で公開されているリポジトリのメタデータが取得されます。前回のビルド以降にリポジトリが更新されていれば、インストールされるパッケージも新しくなる可能性があります。

ubuntu:24.04 というイメージタグも、変化の要因です。ダイジェストによる Docker イメージの固定や、取得済みイメージを保持する仕組みを使っていなければ、同じタグから更新後の内容が取得されることがあります。

通常の保守では、こうした更新が問題になるとは限りません。しかし、緊急パッチの影響を確認したいときには、調査を複雑にする要因になります。

たとえば、更新前には動いていた PHP アプリケーションが、再ビルド後に動かなくなったとします。エンジニアは、原因が PHP の修正なのか、システムライブラリの更新なのか、ベースイメージなのか、それ以外の依存関係なのかを切り分けなければなりません。

以前のビルドに使ったものを記録・保存していなければ、その特定に多くの時間がかかる可能性があります。

過去の依存関係を保持すると、更新前後を比較しやすくなる

セキュリティ対応では、修正を適用した環境をデプロイすることに加え、変更対象となる環境を正確に把握することが重要です。

パッケージのバージョンやイメージのダイジェストを記録すれば、ビルドに何を使ったかを確認できます。さらに、その依存関係自体を保存しておけば、後から環境を再構築する際に必要なファイルを取得できます。

一般的なパッケージキャッシュは、同じファイルの繰り返しダウンロードを減らすために役立ちます。ただし、削除や有効期限の設定によっては、古い内容が残らない場合があります。一方、過去の状態を保持するパッケージミラーは、以前の依存関係やリポジトリの状態を、後から参照できるようにします。

セキュリティ更新後には、隔離したテスト環境で以前のデプロイ環境を再構築し、修正後のビルドとパッケージ構成を比較したい場合があります。元の依存関係が残っていれば、配布元のリポジトリが更新されていても、変更点を調べやすくなります。

脆弱性を含む古いパッケージは、管理された検証環境で使用するものです。本番環境で使い続けるためではありません。ビルドの記録と併せて保持することで、調査を繰り返し、結果を検証できるようになります。

StableBuild による依存関係の保持

StableBuild は、開発チームが独自のミラー基盤を運用しなくても、外部から取得するビルド依存関係を保持できるようにするサービスです。

Docker イメージ、Ubuntu・Debian・Alpine の OS パッケージ、Python パッケージ、外部 URL からダウンロードするファイルに対応しています。stablebuild.jp

PHP の更新をきっかけに再ビルドしても、変更されるのが PHP だけとは限りません。ビルド時には、外部のリポジトリから Docker イメージや OS パッケージも取得します。前回のデプロイ以降に取得元が変わっていれば、その変化も調査対象になります。

StableBuild の Docker ミラーは、サービス経由で取得したイメージを保持し、その後に配布元のタグが上書き・削除されても、保存済みの内容を取得できるようにします。OS パッケージのミラーでは、日付ごとのリポジトリの状態を保持します。開発者は、対応する依存関係の取得先を StableBuild のミラーに設定して利用します。docs.stablebuild.jp

PHP の脆弱性に対応する際には、こうした仕組みによって、更新対象と、維持したいビルド環境の構成を管理しやすくなります。ただし、古いスナップショットを使い続けても、新しい修正が自動で取り込まれるわけではありません。修正済みの PHP を含むパッケージや取得元へ、明示的に更新する必要があります。

再ビルド後に動作が変わった場合は、保存しておいた依存関係を使って以前の環境を再構築し、比較できます。StableBuild は PHP の修正そのものを開発・提供する仕組みではありませんが、修正適用後の検証を支える依存関係の保持を担います。

PHP2Shell への対応で確認したいこと

まずは、影響を受ける PHP 環境を特定し、適切な修正を適用したうえで、更新済みのランタイムが実際に稼働していることを確認します。

その対応と併せて、ビルドの管理方法も見直せます。

• PHP パッケージの提供元と修正状況を確認する
  インストールされているパッケージを特定し、必要な修正が含まれているかを確認します。バージョン番号だけで判断せず、ベンダーのセキュリティ情報を参照します。
• ビルドのたびに変わり得る取得元を洗い出す
  Docker タグ、OS のパッケージリポジトリ、外部からダウンロードするファイルなどを確認します。
• ビルドの記録を残す
  本番環境にデプロイしたものに対応するイメージのダイジェスト、パッケージのバージョン、依存関係の取得元を記録します。
• 過去の依存関係を取得できるようにする
  内容を変更せず保持する仕組みや、過去の状態を参照できるミラーを利用すると、管理された環境での再検証に役立ちます。
• 意図した変更と、それ以外の変更を区別する
  更新後の動作を検証するときは、セキュリティ修正と、同時に取り込まれた別の依存関係の変更を分けて確認します。

これらの取り組みは、PHP2Shell への対応に限らず、配布元のリポジトリが変わったとき、パッケージが削除されたとき、コンテナイメージが予期せず更新されたときにも役立ちます。

次の緊急更新に備える

PHP2Shell の影響を受けるシステムには、適切なセキュリティ修正が必要です。PHP プロジェクトと、利用している OS や製品の提供元が公開する最新の案内に従って対応してください。

今回の問題は、ビルドに使う依存関係を管理する重要性も示しています。

再ビルドでは、意図した更新以外の変更が取り込まれることがあります。前回のデプロイ後に外部の依存関係が差し替えられたり、削除されたりすれば、エンジニアはアプリケーションの動作が変わった原因を調べなければなりません。

StableBuild を通じて必要な依存関係をあらかじめ保存しておけば、以前のビルドで使った Docker イメージ、OS パッケージ、Python パッケージ、外部ファイルを再び取得できます。保存した内容を使って環境を再構築し、パッチ適用やリリース前後の違いを検証しやすくなります。

過去の依存関係を保持するミラーを、既存のビルドプロセスにどう組み込めるか。詳しくは、StableBuild の機能紹介をご覧ください。