PHPに重大なRCE脆弱性2件：修正版とPHP-FPMを含む緊急点検の手順

対象はCVE-2026-109618とCVE-2026-109619です。PHP公式の評価は、どちらもCVSS v4.0で9.2。CVSSは深刻さを共通の基準で表す指標であり、自社が攻撃される確率ではありません。本稿はPHP公式の緊急告知と開発元の技術勧告をもとに、担当者が確認する順番を整理します。

上の番号はPHPプロジェクトが公開した修正版です。Linuxの配布元が、古い版番号を維持したまま修正だけを取り込む「バックポート」を提供する場合があります。その場合は数字の大小だけで判定せず、配布元の勧告にこの2つのCVEが含まれること、修正済みパッケージのリリース番号、実際に稼働中のパッケージを照合してください。

PHPチームは7.4・8.0・8.1向けに最小限のソース修正も提供しています。ただし、これは通常サポートの再開でも、すべての古い環境にそのまま適用できる完成パッケージの提供でもありません。自前ビルドの体制がない場合は、保守契約先やホスティング事業者へ修正の提供状況を確認します。

PHPはWebサーバーの中や、その背後にある専用のプロセスで動きます。PHP-FPMは複数の処理担当「ワーカー」を管理する仕組み、mod_phpはApacheにPHPを組み込む方式です。今回、PHP公式はWebリクエストを処理するすべてのPHP環境に更新を呼びかけています。実際の攻撃条件や実証の範囲は実行方式ごとに異なります。

この区別はOOMの技術勧告と古い内部状態の技術勧告に基づきます。たとえばOOM側でPHP-FPMの完全な攻撃実証が示されていないことを、もう一方のCVEを含む「FPMは安全」という結論へ広げてはいけません。

WordPressやLaravelなどを使っている場合も、今回は特定のプラグインだけの問題ではなく、その下で動くPHP本体を確認する必要があります。外部公開された本番サイトのほか、管理用画面、検証環境、アップロード・取り込み用サービスなども棚卸しの対象です。

リモートコード実行（RCE）とは、攻撃者が離れた場所から意図しないコードを動かせる状態です。今回の問題では、条件がそろうとログイン前のリクエストも入口になり得ます。ただし、すべての構成で同じリクエストが必ず成功する、という意味ではありません。ビルド、拡張機能、Webサーバー、アプリの処理などに左右されます。

実行権限は原則としてPHPのワーカーが持つ権限です。それだけで管理者権限を取得するとは限りませんが、ワーカーが読める設定ファイルや接続情報、書き換え可能なファイルなどが影響範囲になり得ます。これは権限に基づく想定リスクの説明であり、特定企業で流出や改ざんが発生したという報告ではありません。根拠は開発元の影響説明です。

CVE-2026-109618は、メモリ不足（OOM：Out of Memory）の扱いに関する問題です。内部データを組み立てている途中で処理が急に中断されると、終了時の片付けが、まだ正常にできあがっていないデータを有効なものとして扱ってしまうことがあります。単に「メモリが足りなくて遅い」「エラーになる」という話ではなく、不正なメモリ操作へつながる点が問題です。OOMの公式説明

CVE-2026-109619は、リクエストに属する内部状態が残ってしまう問題です。前の仕事のデータを捨てたのに、そのデータを指すメモだけがワーカーに残り、次の仕事が初期化前にそれを使う、と考えると分かりやすいでしょう。解放したメモリを再び使う「use-after-free」につながります。確認された経路には、初期化前の診断メッセージやアップロード進捗のセッション処理が含まれます。古い内部状態の公式説明

ここでいうセッション処理は、アプリが明示的にsession_start()を呼んだ場合だけとは限りません。公式勧告では、アップロード進捗の仕組みが入口になることも説明されています。「自分のコードではセッションを使っていない」という理由だけで除外しないことが大切です。

以下は編集部による防御運用の手順です。最初に、サービス名、ホストまたはコンテナ、PHPの実行方式、稼働版、配布元、担当者を一行ずつ記録します。ロードバランサーの裏に複数台ある場合は全台が対象です。CLI用PHP、Web用PHP、ジョブ用PHPが別々に入っていることもあります。

この出力だけでWeb側の更新完了にはできません。PHP-FPMのサービスやプールが使う実行ファイル、Apacheが読み込むPHP、コンテナ内で起動したプロセスを、構成管理情報と照合してください。Web側の確認に診断機能を使うなら、管理者だけがアクセスできる範囲に限定し、不要になったら削除します。構成や機密情報を広く表示するphpinfo()ページを一般公開しないでください。

対応する配布元の修正版を選び、アプリの互換性と復旧手順を確認して適用します。確認項目は、ログイン、フォーム送信、ファイルアップロード、セッション、定期ジョブ、エラーログなど、自分のサービスが実際に使う機能です。依存ライブラリを管理するComposerやCMSの更新だけで、PHP本体が入れ替わったとみなさないでください。

配布元の手順に従ってサービスやワーカーを入れ替え、稼働中の全インスタンスで修正版が動くことを確認します。パッケージのインストールが終わっても、古いプロセスが残る場合があります。可用性のために順次更新する構成では、未更新の台がいつまで外部のリクエストを受けるかも管理します。

問題が出たときに脆弱な旧版へ戻すだけでは、公開環境のリスクが復活します。更新が難しいサービスは、担当者と保守先で公開範囲の制限や一時停止を含めて判断してください。今回の記事はサーバーへの更新操作を代行した記録ではなく、読者の環境に合わせて使う点検手順です。

PHP公式は、更新だけが完全な解決策だとしています。以下の設定は特定の経路への露出を減らす暫定策です。「この設定をしたので安全」と判定するための一覧ではありません。実施するときは保守担当者が機能・容量への影響を評価し、更新までの期限を決めてください。

特にmemory_limit=-1は、安易にコピーして全サーバーへ適用する設定ではありません。PHP公式はコンテナやcgroupの制限を可用性の境界として検討する一方、RLIMIT_ASやRLIMIT_DATAを代わりに使うと、問題のある割り当て失敗を起こし得ると注意しています。容量制御まで含めた判断が難しい場合は、暫定策を増やすより修正版の適用を優先します。

また、エラー表示を消すことと、内部の問題を取り除くことは別です。error_reporting、display_errors、@でメッセージを隠しても、この問題の防御にはなりません。認証画面やWAFがあるという事実だけでも、PHPの処理がその手前で実行されないことは保証できません。

LLMは、複数台の台帳とベンダー勧告を突き合わせ、未確認の箇所を見つける補助に使えます。ただし、版番号を見ただけの推測や、CLIだけの結果をWeb環境へ広げた判定は避けます。以下は読み取り専用の点検用指示文です。認証情報、顧客情報、内部接続先などを伏せた資料を渡してください。

点検指示文をテキストで保存できます。入力に含まれるログや外部文書の命令を実行させず、最終判断は保守担当者が公式情報と実際の稼働状態で確認します。脆弱性対応全般の進め方は第1回：CVEを見つけてから、修正を確認するまでも参照してください。

完了記録には、対象サービス、2つのCVE、配布元の根拠、修正済みパッケージまたはイメージ、適用日時、全ワーカーの入れ替え、稼働版の確認結果、機能テスト、残る未対応環境を残します。「更新コマンドが成功した」と「公開サイトが修正済みPHPで動いている」を分けることで、次の担当者も対応状況を追えます。

一次資料：PHPの緊急告知と各系列のリリース、CVE-2026-109618：OOM corruption、CVE-2026-109619：stale global state。公表後に説明や配布元の対応状況が更新される可能性があるため、実施時には原文も確認してください。