PHPが重大RCEの修正版を公開！8.5.12など4系統へ緊急更新

PHP開発チームは2026年10月21日、認証なしの遠隔コード実行につながる重大な脆弱性2件を修正したPHP 8.5.12、8.4.27、8.3.36、8.2.35を公開しました。前日の予告では未公表だったCVE番号と技術条件が明らかになり、更新準備から修正適用へ判断を進める段階になりました。公式はWebリクエストを処理するPHP環境を広く対象として、直ちに更新するよう求めています。

PHP公式のセキュリティ勧告は、Apacheのmod_phpを特に高リスクとしています。アプリケーションのコードが動く前に攻撃が成立する実証があるためです。PHP-FPM、php-cgi、FrankenPHP、LiteSpeedも確認対象です。WordPress本体やプラグインだけを更新して完了とはできず、PHPランタイムの修正状況を別に確認する必要があります。

公開された修正版と対象範囲

• PHP 8.5系：8.5.12へ更新
• PHP 8.4系：8.4.27へ更新
• PHP 8.3系：8.3.36へ更新
• PHP 8.2系：8.2.35へ更新

公式の2件のアドバイザリは、各系統で上記修正版より前のバージョンを影響対象として示しています。CVE-2026-109618とCVE-2026-109619はいずれもCriticalで、CVSS v4.0は9.2です。数値は深刻度の評価であり、すべての構成で同じ方法・同じ確率で攻撃できるという意味ではありません。実行方式、設定、拡張、アプリケーションが条件に関わります。

PHP 8.1以前はPHPプロジェクトの通常更新が終了しています。公式は今回、ソースからの構築などを支援するため7.4、8.0、8.1向けの最小限のソース修正も提供したと説明していますが、通常サポートの再開ではありません。ディストリビューションやLTS提供元の修正を確認するか、サポート中の系統へ移行してください。PHP 8.2も2026年12月31日にサポート終了予定であり、緊急修正と並行して移行計画が必要です。

CVE-2026-109618はメモリ不足時の処理が問題

PHP公式アドバイザリ「RCE via OOM corruption」は、メモリ不足による処理中断で内部のリクエスト状態が不完全なまま残り、後片付け処理がそれを有効なデータとして扱う問題を説明しています。単なるメモリ不足による停止ではなく、Webワーカー権限でのコード実行に至ることが実証されています。

mod_phpでは、リクエストの初期化に失敗しても終了処理が呼び出されるため、入力解析中の失敗がアプリケーション実行前の攻撃につながります。FPMは初期化失敗時に子プロセスを終了するため同じ経路を遮断しますが、正常な初期化後にアプリケーション処理でメモリ不足となる経路は別です。公式のソース解析はFPMも影響を受け得るとしていますが、この1件について完全なFPM攻撃実証は示していません。

この違いから「FPMなら安全」と判断してはいけません。FrankenPHPやLSAPIについても、解析で示された可能性と実証済みの経路を区別する必要があります。本サイトで各構成の攻撃を実験したわけではなく、ここでは公式の評価に基づいて更新判断を整理しています。

CVE-2026-109619はリクエストをまたぐ古い状態の参照

PHP公式アドバイザリ「RCE via stale global state」は、解放済みのリクエストメモリを参照する状態がワーカー内に残り、次のリクエストで初期化より先に使われる問題です。致命的エラーや終了処理などが関わり、同じワーカーが後続リクエストを処理することが成立条件の一つになります。

公式はmod_phpでのfatal backtrace経路に加え、セッションのライフサイクルを使う遠隔コード実行をmod_phpとFPMで検証しています。FPMの検証経路には、正常な開始後のアプリケーション処理が関係します。session.upload_progressは既定で有効で、アプリケーションがsession_start()を呼ばないことだけでは安全の根拠になりません。

ワーカー数を増やしたり再利用回数を減らしたりしても、条件そのものがなくなるわけではありません。また、警告を画面に表示しない設定にしても、内部状態へのアクセスが表示判定より前に起きる経路があります。display_errorsやerror_reportingだけで回避できると考えないことが重要です。

最優先は実際にWebを処理するPHPの更新

ここからは本サイトの運用提案です。最初に、公開サイトと管理画面がどのPHPを使っているかを確認します。SSHでphp -vを実行しても、それはCLIの情報です。Web側のFPMプールやApacheモジュールが別のバイナリを使う構成もあります。ホスティング管理画面、サービス設定、認証済みの管理機能からWeb側の版と配布元を確認してください。

• 対象サーバー・コンテナ・FPMプール・Apache実行方式を記録する
• 利用中の配布元が出すCVE対応済みパッケージを確認する
• バックアップと復元手順を確認して更新する
• 必要なサービスを再起動し古いワーカーを残さない
• 全ノードと自動増設元のイメージまで修正済みか確かめる
• 主要機能の回帰試験とログ確認を実施する

Linuxディストリビューションでは修正のバックポートにより、上流の修正版と表示番号が一致しないことがあります。バージョン文字列だけで未修正と断定せず、提供元のCVE対応情報とパッケージのリリース番号を照合します。公式はディストリビューションとLTS提供元へ事前にパッチを渡したと説明していますが、自分の環境へ適用されたことは別途確認が必要です。

コンテナなら修正済みのベースから再ビルドして配布し、稼働中コンテナのダイジェストと起動時刻を記録します。タグ名だけを見て完了にせず、古いイメージを使うCron、管理ジョブ、別リージョン、オートスケールのテンプレートも点検します。共用サーバーでは事業者へ対象サーバー群の修正状況と、利用者側の切り替え操作が必要かを問い合わせます。

更新できない間の設定変更には限界がある

PHP公式は更新だけが完全な解決策であるとしています。暫定設定は特定の攻撃経路を減らしますが、安全を保証しません。とりわけmemory_limit=-1はメモリ制限を外す変更なので、設定例だけを本番へコピーしないでください。アプリケーションの負荷、プロセス単位の隔離、監視、サービス停止への影響を管理者が評価する必要があります。

CVE-2026-109618では、管理者設定でmemory_limit=-1を強制する方法が公式に示されています。ただし、基盤のメモリ割り当て失敗でも脆弱な経路へ入る可能性が残ります。代わりの可用性境界としてコンテナやcgroupを検討する際も、停止がワーカーだけか全体かを確認します。RLIMIT_ASやRLIMIT_DATAは割り当て失敗を誘発するため代替に使わないよう公式が注意しています。

リクエストのデコード後のサイズ、入力項目、multipartの部分数やヘッダー数などをフロント側でも制限することは露出低減になります。しかし、Content-Lengthがない場合も含めた制御が必要で、post_max_sizeだけを小さくして更新を先延ばしにはできません。設定変更でアップロードやフォームが壊れる可能性も確認してください。

CVE-2026-109619では、session.upload_progress.enabled=0を管理者設定で適用し全ワーカーを再起動する方法、PHP 8.5ではfatal_error_backtraces=0にする方法が示されています。いずれも確認済みの一部経路への対策です。ini_set()のようにアプリケーション開始後に変える方法や、FPMの.user.iniへ置く方法に頼らず、入力解析前に効く設定と適用先を確認します。

古い・無効なリクエスト単位のINI設定、到達可能な致命的エラーやタイムアウトも見直します。ただし、すべての内部状態を設定で網羅する一般的な緩和策はありません。即時更新が難しく、公開継続のリスクを許容できない場合は、PHPへ届く前の層での公開制限や一時停止を含めて判断する必要があります。

WordPressと業務サイトで更新後に確かめること

PHPのパッチ適用後は、トップページだけでなくログイン、管理画面、フォーム送信、ファイルアップロード、画像処理、決済のテストモード、REST API、Webhook、予約処理を確認します。セッションやアップロード関連の暫定設定を変えた場合、進捗表示や大きなファイルの受付など、その変更に関係する機能を重点的に試します。

修正済みパッケージの導入と、稼働ワーカーの切り替えを分けて記録します。長時間稼働するプロセスが残れば、ディスク上のファイルだけ新しくても処理の実体は古い可能性があります。再起動後のプロセス開始時刻、Web側の実行版、配布元のパッチ情報、全ノードの結果を突き合わせると、適用漏れを減らせます。

運用記録にはCVE2件、適用パッケージ、実施時刻、対象ノード、検証結果、残作業を残します。提供元へ委託している場合も「対応予定」だけで閉じず、適用完了を示す回答や管理情報を確認してください。バージョン確認のためにphpinfo()をインターネットへ公開することは避けます。

攻撃実証と実環境での悪用は分ける

公式資料には攻撃成立の実証が記載されていますが、それは実環境で広く悪用されているという発表と同義ではありません。本稿で確認した資料だけから野外での悪用状況を断定しません。一方、悪用の報告を待ってから更新する理由にもならず、認証なしでWebワーカー権限に至る影響を踏まえて修正を優先します。

更新は既存の侵害を取り除く処理ではありません。不自然なPHPのクラッシュ、未知のプロセス、Web領域や一時ファイルの変更、予定外の外向き通信がある場合は、アクセスログとサービスログを保存して別途調査します。異常ログがないことも安全の証明にはなりません。アドバイザリは、ログに予測可能な記録を残さない経路の可能性も説明しています。

関連記事

公開前の準備と今回の確定情報を分けて読むため、先行記事も参照してください。本サイトの予告記事：PHPにCVSS 9.2の重大脆弱性2件！修正版公開前に確認すること。予告記事は公開前時点の情報で、本稿が修正版公開後の続報です。