サイト運営・セキュリティ

PHPの緊急更新で何を確認する？サイト運営者のための対策チェックリスト

CVE-2026-109618・109619の公式情報を整理。実際のPHP環境、提供元の修正適用、バックアップと更新後の確認を、WordPress利用者にも分かりやすく解説します。

公開日：2026.10.23 ／最終更新：2026.10.23 ／読了：約7分

まず確認したいのは、WordPressの更新ボタンではなく、そのサイトで実際に動いているPHPと、提供元による修正の適用状況です。この記事では公式確認済みの事実、一般的な対処、編集部の見解を分けて整理します。

情報確認：2026年10月23日 12:29 JST。公式情報は更新されるため、作業時には提供元の最新案内も確認してください。

1. 公式確認済み：何が公表されたのか

PHPは10月21日付の公式告知で、認証なしの遠隔コード実行につながる可能性がある重大な脆弱性2件の修正版を案内しました。IPAは10月22日に正式な注意喚起を公開しています。両件の評価はCVSS v4.0で9.2、Criticalです。

CVE-2026-109618はメモリ不足時に不完全な内部状態が扱われる問題、CVE-2026-109619は解放済みメモリを参照する状態がワーカーに残り、後続の要求処理に影響する問題です。成立条件は実行方式や設定によって異なります。

PHP公式はPHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedを含むWebリクエスト処理環境を更新対象としています。LiteSpeedという名称だけで影響なしとは判断できません。一方、すべての方式で攻撃が実証された、すべてのサイトが侵害された、という意味でもありません。

PHP公式告知を確認する／ IPAの対象・対策を確認する

2. 修正版の目安と、番号だけでは分からないこと

公式が案内した系列別の修正版
系列	影響対象の目安	今回の修正版
PHP 8.2	8.2.35未満の同系列	PHP 8.2.35
PHP 8.3	8.3.36未満の同系列	PHP 8.3.36
PHP 8.4	8.4.27未満の同系列	PHP 8.4.27
PHP 8.5	8.5.12未満の同系列	PHP 8.5.12

これは上流PHPの修正版の目安です。OSやホスティング提供元が修正をバックポートし、表示番号が古いままの場合もあります。番号だけで対策済み・未対策と決めず、両CVEへの対応を提供元の告知や回答で照合してください。

PHP 8.1以前は通常のセキュリティサポートを終了しています。ただしPHP公式は7.4・8.0・8.1向けの最小限のソース・バックポートにも言及しています。旧版には修正が一切ないと決めつけず、ベンダー対応を確認し、サポート対象の系列への移行を検討しましょう。

3. 一般的な対処：実際の環境と提供元を確認する

WordPressでは「ツール → サイトヘルス → 情報 → サーバー」で、そのサイトが実際に利用しているPHPを確認できます。複数サイト・サブドメインがある場合は、それぞれの環境を確認します。管理画面の選択肢や別のコマンド環境の番号だけを、そのサイトの稼働版と同一視しないでください。

提供元の告知で、CVE-2026-109618とCVE-2026-109619の両方、利用中サーバーへの適用完了、利用者側の切替操作や再起動の要否を確認します。共有サーバーでは、修正パッケージの配布だけでなく、稼働中のPHPプロセスへ反映されたかも提供元に確認しましょう。

「メンテナンス終了」は作業時間帯の終了を示すことがあります。今回の修正が自分のサーバーへ適用されたという回答とは分けて確認してください。不明なら、対象サーバー・両CVE・適用状況・必要な操作をまとめて問い合わせると確認しやすくなります。

WordPress公式の今回の案内

4. WordPressの更新とPHPの更新を分ける

今回の問題はPHP本体のものです。WordPress公式は、この問題のためのWordPress更新は不要で、予定もないと説明しています。WordPress本体・テーマ・プラグインを最新に保つ通常の保守は大切ですが、それだけでホスト側のPHP修正を代替することはできません。

5. バックアップ、互換性、更新後の動作を確認する

変更前にサイトのファイルとデータベースを保存し、復元できる場所・担当者・手順を確認します。利用するテーマやプラグインのPHP互換性を確認し、可能なら検証環境で試してから提供元の手順で更新します。

変更後は実際のPHPと修正反映を再確認し、表示、ログイン、フォーム送信、購入や予約など重要な機能を点検します。不具合時は提供元へ相談し、復元や切戻しで脆弱な版へ戻るリスクも含めて判断してください。

すぐ更新できない場合は提供元や保守担当者へ相談します。WAFや設定変更だけを完全対策とせず、一時停止を含む判断は業務への影響と残るリスクを整理して行いましょう。この記事ではメモリ上限の撤廃など、環境ごとに危険性が変わる設定のコピペ手順は案内しません。

更新準備の考え方をWordPress公式で確認する

6. 編集部の見解：修正・侵害・停止は別々に確認する

ここからは編集部の運用上の見解です。「直したか」「侵害されたか」「止めたか」を1つの状態にまとめない方が、関係者へ正確に説明できます。次の表は確認を分けるための整理です。

編集部による3つの確認軸
確認軸	確認する根拠	それだけでは言えないこと
修正適用	提供元の適用回答と稼働環境への反映	過去にも侵害がなかったこと
侵害の有無	保守担当者によるログやファイル等の調査	更新済みという事実だけで侵害を否定すること
サービス停止	停止理由、対象、再開の判断条件	予防的な停止だけで侵害を断定すること

提供元の停止やメンテナンスを見て、侵害が起きたと決めつける必要はありません。一方、更新済みという事実も、過去の侵害がなかった証明にはなりません。確認できた事実と未確認事項を分けて記録することをおすすめします。

公式資料とこの記事の範囲

情報確認：2026年10月23日 12:29 JST。公式情報は更新されるため、作業時には提供元の最新案内も確認してください。

この記事は一般的なサイト運営のための情報整理です。WorkFrame Hub自身のPHP実行環境、侵害の有無、対策完了を宣言するものではありません。個別サイトの状態は提供元・保守担当者と確認してください。

短いお知らせを読む