WordPress公式がPHP緊急更新を要請｜サイトヘルスと保守担当で確認すること

WordPress公式は2026年10月21日、PHPの重大脆弱性を受け、サイト所有者へPHPを速やかに更新するよう呼びかけました。今回の問題はWordPress固有ではありません。WordPress本体の更新通知が出るのを待っても、サーバー側のPHPに必要な修正を適用したことにはなりません。

WordPress公式の緊急案内を10月22日に確認しました。本記事は今回のCVE-2026-109618・CVE-2026-109619への対応を、サイト所有者と保守担当が情報を受け渡す手順として整理します。公式に確認できる内容と、本サイトが提案する確認作業を分けて説明します。

WordPress本体の更新を待つ案件ではない

WordPress公式は、今回の問題に対するWordPressの更新は必要なく、予定もないと説明しています。対象はPHPアプリを動かすサーバーです。WordPress、テーマ、プラグインが最新であっても、それだけでPHPの修正状況は分かりません。

これはWordPressの通常の保守が不要になったという意味ではありません。今回の緊急作業を、管理画面の「更新」だけで完結するものと考えないための区別です。PHPを提供するホスティング会社、サーバー管理者、保守会社の情報へつなげる必要があります。

本サイトでは、対応記録の冒頭に「今回確認するのはPHPランタイム」と明記することを勧めます。サイトの担当者が複数いる場合も、プラグイン更新の完了報告と、サーバー側PHPの修正完了を別の項目にできます。

サイトヘルスでサイト側のPHPを確認する

公式案内が示す確認場所は、WordPress管理画面の「ツール→サイトヘルス→情報→サーバー」です。まず管理権限を持つ担当者が、このサイトで表示されるPHPの版を確認します。ホスティングの管理画面でも確認できる場合がありますが、別サイトの設定を見ないよう対象ドメインを照合します。

サイトヘルスの公式資料は、ステータス画面と、環境の詳細を確認する情報画面を区別しています。今回の確認では、診断の総合表示だけを見るのではなく、情報側でPHPの具体的な値を取得することが大切です。

記録には対象URL、PHPの版、取得した日時、確認者を付けます。複数サイトを管理している場合は一サイト一行にします。あるサイトで修正版が見えたことを、同じ会社が契約する全サイトの結果として扱わないでください。

本サイトは、サイトヘルスの表示が良好であることを、今回のCVEへの修正証明とみなさない方法を提案します。表示される値と、PHPの配布元が示す修正番号を照合する工程を、別に置くためです。

修正番号はPHPの配布元と一緒に確認する

PHPプロジェクトが公開した修正版は、8.5.12、8.4.27、8.3.36、8.2.35です。ただし、OSや管理パネルが独自に修正を取り込む場合があるため、先頭の版番号だけで全環境を判定することはできません。修正済みかを説明するには、どの配布元のPHPかという情報も必要です。

例えば、OS配布元が従来のPHPへ修正を取り込んで配布する構成と、上流PHPと同じ番号のバイナリーを利用する構成では、確認する版の表記が異なります。サイトヘルスで見える番号だけでは判定できないときは、保守担当へパッケージ版やビルド情報の確認を依頼します。

逆に、配布元が分からない旧PHPについて、どこかの事業者が修正したという理由だけで安全と扱うこともできません。利用中のサービス名やサーバー構成と結び付く告知が必要です。ここで不明な情報は推測せず、未確認として残します。

ホスティング会社への問い合わせは対象を具体化する

WordPress公式は、ホスティング会社がPHP更新やWAFによる緩和を進めている場合でも、利用者が提供元の案内を確認するよう求めています。「事業者が対応中」と「自分の契約環境への反映が完了」は区別して扱います。

問い合わせでは、契約情報を公式のサポート窓口へ提示した上で、対象ドメイン、利用中のPHP、今回の二つのCVEを伝えます。以下は本サイトが提案する確認項目です。全項目を公開掲示板へ載せる必要はありません。

• 対象サイトのPHPへ、今回の修正が適用されているか。
• 修正を判定できる版、パッケージ番号、またはビルド情報は何か。
• 適用済みの場合、対象環境への反映はいつ完了したか。
• 利用者側でPHPの切り替えや再起動などの操作が必要か。
• 未適用の場合、暫定対応と次の案内をどこで確認できるか。

回答がWAFの導入だけであれば、PHP自体の修正予定も分けて尋ねます。通信を検査する対策と、実行環境のコード修正は同じではありません。問い合わせの結果を、契約先の告知URLと一緒に保守記録へ残してください。

WP-CLIで見えるPHPはWeb側と同じか

SSHを使う保守担当は、WP-CLIからPHPの情報を調べることもできます。WP-CLIの公式資料にある次のコマンドは、WP-CLIが使うPHPバイナリーや版などの情報を表示します。読み取り用の確認例です。

wp cli info

ただし、これはWP-CLIを動かすPHPについての情報です。Webサーバー経由でWordPressを処理するPHPと、同じ実体であることまでは保証しません。CLIの表示とサイトヘルスの表示を、確認した対象も含めて照合してください。

仮想例として、SSHでは新しいPHPが使われ、Webサイトの設定では以前の系列が選択されたままの構成を考えます。この場合、CLIの版を確認しただけでは公開サイトの対応を完了できません。反対にWeb側が修正済みでも、定期処理など別の実行経路は確認が残る可能性があります。

本サイトでは、Webリクエスト、定期実行、管理コマンドを区別した小さな台帳を提案します。実際に利用している経路だけを対象に、PHPの取得元と確認結果を対応させます。使っていない構成を無理に増やす必要はありませんが、存在が不明なものを確認済みにはしないようにします。

更新前に担当範囲と戻し方を確認する

サイト所有者がサーバーへアクセスできない場合、OS向けの更新コマンドを探して実行する必要はありません。契約先が基盤を保守するのか、利用者が管理するVPSなのかを先に特定します。制作会社がWordPressだけを保守する契約なら、サーバー更新の担当者を別に確認します。

本サイトが勧める準備は、対象サイトと担当者、バックアップ、代表的な確認操作、問題が出た場合の連絡先をそろえることです。緊急対応を先延ばしするためではなく、更新後に不具合が出ても状況を引き継げるようにするためです。

同じ系列内でセキュリティ修正を適用する作業と、古いPHPから大きく系列を変える移行は、互換性の変化が異なります。自分のテーマやプラグインで何を検証する必要があるかを確認し、契約先の手順に従います。緊急修正の提供があるなら、その適用と長期移行を分けて考えられます。

旧PHPは今回の修正と継続保守を分けて判断する

WordPress公式は、PHP 8.2より前の系列はPHPプロジェクトのセキュリティ更新対象ではないと説明しています。自己管理環境で直ちに修正できない場合は、更新準備中の停止も検討するよう案内しています。何もせずに通常運用を続ける判断の根拠にはできません。

一方、OSや製品提供元が別途保守するパッケージは、その提供元の告知で判断します。上流の保守終了と、特定パッケージへの今回の修正提供を混同しないことが必要です。独自の保守があると分かっても、将来の更新範囲や提供期間まで推測しないでください。

本サイトでは、緊急対応欄に今回の修正結果を、移行計画欄に継続利用の条件と次の見直しを記載する方法を勧めます。今回の一件を修正したことが、旧系列の長期利用を正当化する理由にならないように分けて管理します。

更新後はサイトと保守記録を読み戻す

更新後は、サイトヘルスなどでPHPの情報をもう一度確認し、保守担当の修正記録と照合します。画面に見える番号だけでは不足する構成では、配布元の修正版と実体の対応を確認します。作業前のスクリーンショットを、作業後の証拠として使わないよう取得時刻も残します。

動作確認は、トップページだけでなく、ログイン、投稿、フォーム、検索など、そのサイトに必要な操作を少数選びます。問い合わせや決済など外部へ影響する操作は、通常の試験方法で確認してください。本サイトが読者のサイトで実測・試験したという意味ではありません。

不具合への切り戻しで、修正前のPHPまで戻る可能性もあります。復旧手順は保守担当と確認し、必要なら公開範囲の一時制限を含めて判断します。修正を失う復旧を行った場合は、対応完了の記録も見直す必要があります。

最終的に残したいのは、対象URL、PHPの配布元と修正版、反映の完了時刻、動作確認の結果、未確認事項です。WordPressの更新通知の有無ではなく、サイトで動くPHPへの修正を説明できる状態を目指します。

関連記事

• PHP重大RCEの修正版と更新対象を確認する：今回の脆弱性とPHP側のリリースを整理しています。
• 国内ホスティング各社のPHP緊急修正対応：契約サービスの告知と、利用者側に残る確認を調べるための記事です。