PHPの重大RCE2件と追加告知：修正版・アップロード進捗の点検手順

10月29日追記：Linux側も確認してください。 CISAの10月28日付KEVデータは、PHPのCVE-2026-109618・CVE-2026-109619とLinuxのCVE-2026-46300（Fragnesia）を連鎖させ、Webシェルの設置やroot権限での実行につなげ得ると記載しています。PHPの更新と別に、稼働カーネルと侵害調査の状況を確認してください。Linux側の対象・修正確認はこちら。

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

PHPの10月23日付追加告知は、セッションのアップロード進捗に関わる別の問題を説明しています。10月21日に修正された2件とは分けて扱います。公式は成立条件が珍しいため通常の修正サイクルで対応し、次回リリース時に詳細勧告を出すとしています。10月24日15時台（日本時間）の確認時点で、この追加問題の修正版番号・影響版の網羅的な範囲・CVSSは同告知に示されていません。先の2件の9.2という評価を転用しません。

セッションの保存形式は、ログイン状態などのデータを保存・読み戻しする方式です。公式は、実行中に保存形式を切り替えないアプリは進捗機能を有効のままにできると説明しています。条件が分からない場合は、設定だけでなくアプリや共通ライブラリの処理順も担当者が確認してください。

公式が案内する当面の対処はsession.upload_progress.enabled=0です。10月21日の対策ですでに無効にした場合は維持します。これは追加問題についての案内であり、先の2件の修正版への更新を省略できるという意味ではありません。下の修正版表も先の2件に対するもので、CVE-2026-115560まで修正済みと読まないでください。

運用上は、Web側で有効になる設定を保守担当者が確認し、配布元の手順で反映・ワーカーの入れ替えを行い、全台で確認します。進捗表示を利用する画面への影響もテストします。PHPマニュアルではこの設定はINI_PERDIRであり、アプリ内のini_set()だけで無効化する手順にはしません。CLIでの設定表示だけでWeb側にも反映済みとは判定しないでください。ここまでの点検は編集上の運用提案で、実環境の変更や攻撃再現は行っていません。

悪用状況も日付を付けて読みます。NCSC-NLの10月23日15時45分更新は、先の2件について海外で悪用の可能性がある報告を1件把握したものの、攻撃の成功は未確認と説明し、大規模な悪用の可能性を従来より低く見積もっています。一方で、速やかな更新の勧告は維持しています。これは同機関の観測であり、世界中で悪用がないという保証ではありません。

JPCERT/CCの10月22日の注意喚起は、速やかな対策と侵害有無の調査を求めています。過去のHTTPレスポンスで設定された、不自然に長い／異常形式のPHPSESSID Cookie、不審なmultipart/form-dataのリクエストと周辺のメモリ上限・HTTP 500エラー、ワーカーの異常終了や頻繁な再起動などを、他の不審なファイル・プロセス・外部通信と合わせて確認します。

これらが見つからなくても、攻撃を受けていないとは断定できません。単一の検知ルールですべての経路を検出できるわけではなく、ログに残らない場合もあります。疑いがある場合は関連ログを保全して担当者が調査・隔離を判断します。注意喚起の公表を、国内で実悪用が確認されたという発表と読み替えないでください。

上の番号は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公式は、10月21日公開の2件について更新だけが完全な解決策だとしています。以下の設定は特定の経路への露出を減らす暫定策です。「この設定をしたので安全」と判定するための一覧ではありません。実施するときは保守担当者が機能・容量への影響を評価し、更新までの期限を決めてください。

特に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。公表後に説明や配布元の対応状況が更新される可能性があるため、実施時には原文も確認してください。