PHPの重大な脆弱性を受けてWordPressの運営者がまず行うことは、契約サーバーの対応状況と、自分のサイトで実際に使われているPHPのバージョンを確認することです。
WordPressの更新ボタンを押すだけで、今回のPHPの問題まで解消するとは限りません。
2026年10月23日時点では、PHP公式が今回の修正版として案内しているのは8.2.35、8.3.36、8.4.27、8.5.12です。
ただし、提供会社が修正を取り込んだ独自のパッケージを使う環境もあるため、数字だけで判断できない場合は提供元に確認します。
この記事では、個人ブログや小規模サイトの運営者が、何をどの順番で確認すればよいかを整理します。
今回はWordPress本体とPHPを分けて考える
PHPは、WordPressの記事表示や管理画面などを動かす、サーバー側のプログラム実行環境です。
WordPress本体、テーマ、プラグインを動かす土台に当たります。
そのため、管理画面に「WordPressは最新です」と表示されていても、PHPも修正済みとは判断できません。
PHP公式の2026年10月21日付発表では、認証を経ずに外部からコードを実行されるおそれのある、2件の重大な問題への更新が案内されています。
脆弱性の識別番号はCVE-2026-109618とCVE-2026-109619です。
問い合わせの際は、この番号があると、別のPHP関連情報と取り違えにくくなります。
WordPress公式の日本語案内も、サイト所有者にPHPの更新を求めています。
今回の問題はWordPress固有の不具合ではなく、PHPの実行環境にあるという説明です。
ここで区別したいのは、「サーバー会社が作業したか」と「自分のサイトが対策された環境を使っているか」です。
サーバー会社のお知らせを読んだら、対象サービス、対象サーバー、作業の完了状況、自分で切り替える必要の有無まで確認してください。
単に「更新予定」と書かれた古いお知らせを見つけただけでは、対応完了の確認にはなりません。
最初に確認するのは使用中のPHPと公式のお知らせ
WordPressの管理画面では、「ツール」から「サイトヘルス」を開き、「情報」の「サーバー」でPHPバージョンを確認できます。
これはWordPress公式も案内している確認方法です。
まず、その数値と確認日時を控えておきましょう。
続いて、契約しているレンタルサーバーの公式サイトで、障害・メンテナンス情報やセキュリティのお知らせを確認します。
検索結果の見出しだけで済ませず、本文の更新日と追記まで読むのがポイントです。
利用サービス名が似ていても、個人向けと法人向けでは案内が別になっていることがあります。
公式に案内された今回の修正版は、8.2系列なら8.2.35、8.3系列なら8.3.36、8.4系列なら8.4.27、8.5系列なら8.5.12です。
たとえば8.3.36は、今回の問題に対応するために案内された8.3系列の版です。
「8.3と書かれているから大丈夫」と省略せず、末尾の数字まで確認します。
一方、OSやサーバー提供会社が、従来の版にセキュリティ修正だけを取り込む「バックポート」を行うこともあります。
この場合は画面の数字が公式配布版と一致しない可能性があるため、提供元の対策済みという説明を照合します。
自分で判断できなければ、使用中の版と2件のCVE番号を添えて問い合わせる方が確実です。
複数のブログを持っている人は、ブログごとに確認してください。
確認用メモには、ドメイン名、使用中のPHP、提供会社の対応状況、確認日時の4項目があれば役立ちます。
1サイトの確認結果を、そのまま別のサイトにも当てはめないようにします。
更新が必要な場合はバックアップと動作確認を組み合わせる
未対策だと分かった場合は、提供会社の手順に沿って、対策済みPHPへ更新・切り替えを行います。
PHPの系列を大きく変える場合には、使っているテーマやプラグインとの互換性も確認が必要です。
数字が最も大きい版を選ぶことだけを目標にせず、修正済みで、サイトが正常に動く環境を選びます。
自分で切り替えを行う前には、利用できるバックアップと復元方法を確認しましょう。
WordPressでは、画像などのファイルと、記事や設定を保存するデータベースの両方が復旧に関わります。
サーバーの自動バックアップがある場合も、保存対象と復元操作の場所を確認しておくと、異常が出たときに迷わずに済みます。
すでに必要なバックアップを確保できるなら、今回のためだけに複数のバックアップ用プラグインを追加する必要はありません。
新しい仕組みを増やすより、今あるデータを戻せるか確認することが先です。
ただし、準備を理由に未対策のまま放置するのではなく、更新の予定を具体的に決めて進めます。
切り替え後は、トップページだけでなく、個別記事、管理画面、画像表示、普段使う機能を確認します。
下書きの保存やプレビューも試すと、閲覧だけでは分からない問題に気づきやすくなります。
問い合わせフォームなどがある場合は、実際の運用に支障がないかも確かめましょう。
確認は、一度にたくさん設定を変えずに行うと整理しやすくなります。
PHP変更と同時にテーマ交換や不要なプラグイン追加まで行うと、問題が起きたときに原因を追いにくくなるためです。
異常が出た場合は、対策済みの代替環境や復旧手順を提供会社に相談してください。
動いたからという理由だけで、未対策の古いPHPへ戻した状態を継続しないようにします。
WAFや正常表示だけでは更新の代わりにならない
WAFは、不審な通信を検知・遮断するための仕組みです。
サーバー会社が今回の問題に対するルールを追加している場合もありますが、PHP公式は、更新だけが完全な対処だと説明しています。
WAFを有効にしたことと、PHPそのものの修正が済んだことは分けて確認します。
また、サイトが普段どおり表示されることは、動作確認として大切です。
しかし、正常に開けたという事実だけで、未修正の問題がなくなったとは判断できません。
「画面が動くか」という確認と、「対策済み環境か」という確認の両方が必要です。
サーバー会社が緊急メンテナンスを行い、管理画面を一時的に止めている場合もあります。
そのときは公式の作業案内を確認し、サービスの停止だけで侵害されたと決めつけないようにしてください。
一方で、案内が見つからない、対象か不明、修正予定が分からないという場合は、そのまま待つ判断をせず問い合わせます。
旧系列を使っている場合は、提供元が今回の修正を用意しているかを特に確認してください。
PHP公式が例外的に提供した旧版向けの最小限の修正ソースがあることと、レンタルサーバー上で自分の環境に適用されていることは別です。
自分でソースを扱わない利用者は、提供会社の説明を基準にします。
対応の区切りを決め、異常があれば別に調べる
今回の確認は、対策済み環境を使っていること、必要な変更が完了したこと、主な機能が正常に動くことを確かめるところまで進めます。
使用中のPHPと確認日時を記録しておけば、同じニュースを見直すたびに、最初から確認し直す手間を減らせます。
ただし、PHP更新は、すでに起きている改ざんを自動で元に戻す作業ではありません。
知らない管理者が増えた、見覚えのないページが出た、別サイトへ転送されるといった異常がある場合は、更新とは別に調査が必要です。
WordPress公式の侵害時の確認案内も参考に、気づいた時刻や症状を記録してサーバー会社へ連絡します。
今日の一手は、WordPressのサイトヘルスでPHPの版を確認し、契約サーバーの最新案内と照合することです。
対策済みか不明なら、ドメイン名、PHPの版、今回のCVE番号をまとめて問い合わせてください。
確認できた事実をもとに、必要な更新と動作確認まで終えることが、運営を続けるための具体的な対応です。
