WordPressのPHP脆弱性を確認する方法｜対応手順と問い合わせ例

公式情報の確認：2026.10.24。10月21日の修正と23日の追加案内を区別しています。個々のサーバーの修正適用や侵害の有無を直接診断したものではありません。

WordPressのPHP脆弱性が心配なときは、サイトの契約先とPHPの管理者を確かめ、公式告知と対応状況を照合します。サイトが開くことや、WordPress本体が最新版であることだけでは、PHPの修正が済んだとは判断できません。

WordPress.comでホストしているサイトは、10月21日付の公式案内では、同日公表の2件について利用者側の対応は不要とされています。ただし、10月23日の限定条件に関する追加案内まで、この説明だけで確認済みとは扱いません。別のサーバーを使っている場合は、契約先の対応告知を確認し、不明点があれば管理者へ問い合わせます。

最初にやること：① 契約先と管理者を確認 → ② 公式告知と対応状況を照合 → ③ 追加作業を判断。分かったことと残った作業は、最後のPHP対応確認記録へ残します。

01今回のPHP脆弱性で、WordPress運営者が確認すること

2026年10月21日にPHP公式が公表した問題では、WordPressを動かすPHPへの対応を確認する必要があります。10月23日には、まれな設定と処理の組み合わせについて追加案内も出ました。2つの確認を分けて進めましょう。

対象の脆弱性：CVE-2026-109618／CVE-2026-109619。公式告知は2026年10月21日付です。これとは別に、10月23日の追加案内はCVE-2026-115560です。以下では日付と対象番号を分けて整理します。

PHP・WordPress本体・テーマやプラグインは更新対象が異なる

PHPは、サーバー上でWordPressを動かすためのプログラムです。WordPress本体や、機能を追加するプラグイン、見た目を変えるテーマとは更新対象が異なります。

WordPressの管理画面で本体を更新しても、それだけでPHPへの修正が済むわけではありません。WordPress.orgも、今回の問題への対処としてWordPress本体の更新は予定していないと案内しています。

根拠：WordPress.orgの公式案内

10月21日の修正版と、対象を示す2件のCVE番号

CVE番号は、脆弱性を区別するための共通の識別番号です。問い合わせでは「PHPのニュース」だけでなく、10月21日の2件と、10月23日の追加案内の番号を分けて伝えると対象が明確になります。

10月21日の2件のCVEに対する修正版
PHPの系列	10月21日の修正版
8.2	8.2.35
8.3	8.3.36
8.4	8.4.27
8.5	8.5.12

出典：PHP公式・2026年10月21日付のセキュリティ告知。これはCVE-2026-109618／109619の修正を照合する一覧です。CVE-2026-115560の対応完了を示す一覧ではありません。将来も通用する最新版一覧ではなく、全員に8.5への変更を勧めるものでもありません。

10月21日の2件について、PHP公式はWebを提供するすべてのPHPインストールがリスクの対象になると案内しています。「自分の構成なら関係ない」と推測せず、利用環境に修正が適用されたかを確かめます。

10月23日の追加案内｜セッションのアップロード進捗に関する限定条件

PHP公式は2026年10月23日、「Informational advisory: Session upload progress」を公開しました。セッションは利用者の状態を扱う仕組みで、ここで問題になるのは、保存形式を実行中に切り替える処理とアップロード進捗機能の組み合わせです。

追加案内の対象は、次の条件がすべて重なるまれな構成です。WordPressを使っていることだけでは、該当すると判断できません。

設定上のsession.serialize_handlerがphp_binaryまたはphp_serializeになっている。
アプリケーションがsession_start()を呼ぶ前に、ini_set()でその値をphpへ実行時に切り替える。
セッションのアップロード進捗が有効になっている。

PHP公式は、この経路への保護として、次の通常バグ修正リリースまでsession.upload_progress.enabled=0を推奨しています。すでに無効化している場合は維持し、この追加案内に関する追加対応は不要です。実行中に保存形式を変更しないアプリケーションは、進捗機能を有効のままにできると説明しています。

この設定は10月21日のCVE-2026-109619の緩和策にも含まれていました。ただし、進捗機能を無効化するだけで、10月21日の2件への更新を省略できるわけではありません。修正適用の確認は引き続き必要です。

CVE-2026-115560の詳細な正式勧告は次の通常リリース時に公開予定です。10月23日の案内には、確定した公開日・修正版番号は示されていません。本記事では個別サーバーの設定や実害を確認しておらず、すべてのWordPressサイトが対象とは断定しません。

根拠：PHP公式・10月23日のSession upload progress追加案内と10月21日の勧告

注意管理型ホスティングでは、設定名を見て一律に変更せず、提供元へ対象構成と必要な緩和策を確認してください。自己管理でも、管理者が適用箇所・反映・機能への影響を確認します。この記事のini_set()は対象条件の説明であり、対策コードとして貼り付けるものではありません。

脆弱性・攻撃の試行・実際の被害を分ける

脆弱性があること、誰かが攻撃を試みたこと、実際に侵入や改変が起きたことは別です。今回の問題には、認証なしでコードを実行されるおそれがありますが、ニュースを見ただけで自分のサイトの被害が確定するわけではありません。

根拠：PHPの技術的な公式アドバイザリー

一方、サイトが正常に表示されること、バックアップがあること、有人サポートが付いていることも、被害がない証明にはなりません。まず修正状況を確認し、不審な変化があれば別途、調査を相談します。

02PHPを管理するのは誰？運営形態から確認先を選ぶ

最初に見るのは、サイトを置いているサーバーの契約先と、保守を任せている範囲です。請求明細、ホスティング契約、対象サイトの管理画面を確認します。独自ドメインの有無だけでは判断できません。

小さい画面では、表を横にスクロールできます。

運営形態別・最初の確認先
運営形態	確認する相手・場所	確認すること
WordPress.comでホスト	各告知の日付・対象CVE・サイトへの通知	10月21日の保護案内の対象か、23日の追加条件に関する案内があるか
レンタルサーバー・他社の管理付きサービス	契約サービスの公式告知・管理画面	会社側が適用するか、自分で切り替える必要があるか
制作会社・保守会社へ委託	保守契約の担当窓口	PHPまで管理範囲か、誰が作業し、いつ反映したか
VPS・クラウドなどを自己管理	サーバー管理者・PHPの配布元	修正版の提供状況、適用方法、反映の確認
契約先が分からない	契約書・請求明細・制作担当	ホスティング先とPHPの管理者

WordPress.comでホストしている場合

2026年10月21日付のWordPress.com公式告知では、同社でホストするサイトは10月21日公表の2件から保護されており、利用者の対応は不要とされています。対象のホスティング契約だと確認でき、別途作業の通知がなければ、この2件について全員が問い合わせる必要はありません。

一方、この10月21日の告知だけでは、23日のCVE-2026-115560について、個別サイトの対象該当性や対策状況までは確認できません。追加告知・契約先の回答に対象と必要な作業が明記されていれば保存し、不明なら問い合わせ文で確認します。これは既存の保護が無効になったという意味ではありません。

ただし、WordPress.comでドメインを買ったこと、アカウントを持っていること、Jetpackで接続していることだけでは、サイト自体のホスティング先は確定しません。ドメインの契約と、サイトを動かすサーバーの契約を分けて確認してください。

レンタルサーバーや他社の管理付きサービスの場合

契約しているサービス名まで確認し、そのサービスの告知を読みます。同じ会社でも、プランやサーバーによって対応方法が異なる可能性があるためです。「修正版を提供開始」と「対象サイトへの適用完了」も分けて読みましょう。適用の有無や自分の作業が分からなければ、契約先へ確認します。

制作会社・保守会社へ管理を依頼している場合

保守契約に、PHPやサーバーOSの管理が含まれるかを担当者に確認します。「WordPressの保守」が、本体・テーマ・プラグインの更新だけを指す場合もあるためです。PHPの変更を担当する人が分かるまでは、管理画面の設定を自己判断で切り替えないようにします。

VPS・クラウドなどを自分で管理している場合

サーバー管理者が、利用OSやPHP配布元の修正案内に従って対応します。サーバーを借りているだけで、PHPの更新まで自動で行われるとは限りません。担当者がいない、手順を判断できない場合は、保守を依頼できる窓口へ相談してください。

根拠：自己管理環境についての公式案内

03PHPバージョンと、提供元の修正対応を照合する

表示されるバージョンは、対応状況を調べる手がかりです。数字を記録したうえで、提供元の告知と対象サイトへの適用状況を照合します。

サイトヘルスで対象サイトのPHPバージョンを見る

対象サイトのWordPress管理画面へログインする。
「ツール」→「サイトヘルス」を開く。
「情報」タブの「サーバー」を開く。
PHPバージョンの表示と、確認日時を記録する。

この確認経路はWordPress.orgの今回の案内に基づきます。「8.4」のような系列名だけでなく、「8.4.27」のように表示されている細かい番号まで控えてください。

表示がない・権限がない場合は管理画面や契約先へ

サイトヘルスを見られないときは、サーバーの管理画面や契約先の案内を確認します。分からない部分は「不明」のまま問い合わせて構いません。確認のために、公開サイトへ診断用ファイルを置く必要はありません。

WordPress.comのサーバー設定については、公式のサーバー設定ヘルプを参照してください。画面の経路や表示できる項目には違いがあります。対象のCVEについて追加作業不要と案内された人が、数字を合わせるためだけに設定を変更する必要はありません。

系列名・バックポート・修正版の提供と適用を区別する

提供元が、古い系列へ必要な修正だけを取り込むことがあります。これをバックポートと呼びます。PHP公式も、利用している配布元や長期サポート提供元の更新を確認するよう案内しています。

根拠：PHP公式の修正・サポート案内

ただし、「バックポートされているかもしれない」は対応済みの根拠になりません。今回のCVE番号に対する修正と、自分のサービスやサイトへの適用を、提供元の告知・回答で確認します。

数字が古い：それだけで未対応と断定せず、配布元の修正状況を確認する。
修正版が選べる：現在そのサイトで使われているかを確認する。
10月21日の修正版を使用：同日の2件の修正確認の根拠にはなるが、23日の追加条件の確認とは分ける。サイト全体の安全も保証しない。

PHP 8.1以前のようにPHP公式の通常サポートが終了した系列は、継続保守の有無も確認が必要です。配布元独自の修正を使う場合も、今後の保守計画を管理者と相談しましょう。

04不明点が残るときの問い合わせ文｜影響・修正・追加作業を聞く

問い合わせ前に、告知の対象サービスとCVE番号を確認する

公式告知が自分の契約サービスと確認したいCVEを対象にしており、追加作業の有無まで分かれば、その案内を記録できます。対象や適用状況が分からない場合に、公式のサポート窓口へ問い合わせましょう。別サービスの利用者が受けた返信や、一般的なAIの回答は、自分のサイトへの適用確認の代わりにはなりません。

対象サイトとCVE番号を伝える文例

［］の部分を置き換えて使えます。不明な項目は推測で埋めず、「不明」と記入してください。

サポートへの問い合わせ文

件名：対象サイトのPHP脆弱性対応状況の確認

運営しているサイトについて、次のPHP脆弱性への対応状況を確認したいです。

対象サイト：［URL］
契約サービス：［分かる範囲で記載］
対象①：10月21日公表のCVE-2026-109618／CVE-2026-109619
対象②：10月23日追加案内のCVE-2026-115560
公式告知：https://www.php.net/archive/2026.php
表示されているPHPバージョン：［表示内容／不明］
確認日時：［年月日・時刻・タイムゾーン］

1．対象①の2件について、このサイトの実行環境は影響対象でしょうか。
2．対象①の修正は、このサイトの実行環境へ適用・反映済みでしょうか。修正済みバージョン、またはバックポート等の対応を確認できる案内があれば教えてください。WAFなどの暫定保護のみの場合は、その旨も教えてください。
3．対象②は、設定がphp_binaryまたはphp_serializeで、session_start()の前にini_set()でphpへ切り替え、アップロード進捗が有効という構成が対象と理解しています。このサイトは該当しますか。該当する場合、session.upload_progress.enabled=0など必要な緩和策は適用・反映済みですか。非該当の場合は、その旨を教えてください。
4．それぞれの対象について、利用者側で追加の更新、設定変更、動作確認は必要でしょうか。緩和策を維持する期間や、次回の正式勧告・修正リリース後の確認方法も教えてください。
5．未対応・確認中の点があれば、対応予定と、それまでの推奨対応・次に状況を確認する方法を教えてください。

以上、対象サイトについての対応状況をご確認いただけますと幸いです。

ボタンが使えない場合は、上の本文を選択してコピーできます。

注意パスワード、APIキー、バックアップコードは書かないでください。契約番号などが必要なら、公式の非公開窓口で求められた範囲だけを伝えます。本人確認は、その窓口の案内に従います。

「対応中」「保護済み」という回答の範囲を読む

回答では、どのサイト・CVEが対象か、いつの時点か、何を実施したか、自分の作業があるかを確認します。「対応中」なら完了予定を、「WAFで保護」ならPHPへの修正適用も済んでいるかを聞きます。

WAFは、不審な通信を検知・遮断する仕組みです。攻撃を防ぐ措置と、PHP自体の修正は分けて読み取ってください。公式告知に書かれていないサーバーの適用時刻やパッケージ番号まで、確認済みとして書き足す必要はありません。

05対応状況に応じて、更新・確認終了・追加相談を判断する

確認のゴールは「問い合わせを送った」ことではなく、10月21日の修正状況と23日の追加条件の確認を分け、残っている作業が分かることです。回答や告知を、次の行動につなげます。

小さい画面では、表を横にスクロールできます。

確認できた状況から、次の行動を選ぶ
確認できた状況	次の行動	残す根拠
対象サービスの公式告知で、追加作業不要	自分の契約と、どのCVEへの案内か確認して保存。23日の追加条件が未確認なら別に確認	サービス名・対象CVE・公式URL・確認日時
10月21日の2件は修正適用済み	この2件の更新確認を記録。23日の追加条件は、非該当または必要な緩和策の適用を別に確認	対象サイト・CVE・回答日時・適用内容
23日の追加条件に非該当、または必要な緩和策を適用済み	根拠を保存。適用した緩和策は案内どおり維持し、正式勧告・次回修正時に再確認	非該当の根拠または緩和策・確認元・次の確認方法
自分で更新・切替が必要	提供元の手順で準備・適用・動作確認	作業内容・日時・確認結果
対応中・WAFで保護、修正適用は不明	修正予定・当面の保護・自分の作業を再確認	未確認点・窓口・次の確認予定
未対応で、すぐの修正が難しい	管理者へ緊急対応を相談。公開停止なども検討	実施措置・修正予定・管理者の判断
不審な改変などがある	更新とは別に、記録と調査相談を進める	症状・発見時刻・対応履歴

注意「追加作業不要」は、対象の問題とサービスについての判断です。サイト全体の安全や、過去に侵害がなかったことの証明にはなりません。

追加作業不要と確認できた場合は、根拠を保存する

公式告知のURLと確認日、対象サービス名を記録します。問い合わせた場合は、対象サイト・回答日時・回答の要点も残してください。対象CVEについて必要な判断ができていれば、細部を埋めるためだけに同じ問い合わせを繰り返す必要はありません。ただし、10月21日の回答しかない場合に23日の追加条件を確認することは、別の確認です。

利用者側の更新が必要な場合は、提供元の手順で進める

適用先を確認：契約先が提供する10月21日の2件への修正済みPHP環境と、23日の追加条件に必要な確認・緩和策を分けて確かめる。
復旧に備える：サイトのファイルとデータベースをバックアップし、復元方法を確認する。
互換性を確認：WordPress本体・テーマ・プラグインと、変更先のPHPが対応するか確かめる。
手順どおりに適用：サーバー会社や管理者の案内に従って実施する。
適用後を確認：PHPの表示情報、サイト表示、管理画面、フォームや決済など利用している機能を確認する。

バックアップや互換性の確認は、WordPress.orgのPHP更新ガイドも参考になります。ただし、この一般ガイドの推奨系列だけで今回の修正済み判定はせず、今回の告知と照合してください。

準備を理由に重大な修正を無期限に先送りしないことも大切です。更新後に問題が出た場合は管理者へ相談し、脆弱性の残る版へ戻したまま運用を続けないようにします。

未確認・未対応なら、対応予定と当面の保護を確認する

回答待ちであっても、未対応の可能性が残るなら、緊急窓口、修正の予定、当面の保護措置、自分がするべき作業を確認します。「連絡したので様子を見る」だけで終えず、次に確認する日時を記録します。

WordPress.orgは、PHP 8.2より前のバージョンを使う自己管理環境について、更新準備中の公開停止も検討するよう案内しています。すぐに修正できない場合は、停止が必要か、どの方法で保護するかを管理者へ確認してください。

根拠：未修正の自己管理環境についての案内

WordPress内のメンテナンス画面を表示するだけで、PHPへの到達を止められたとは判断しません。PHPの公式アドバイザリーにはアプリケーション実行前の処理に関する問題も記されているため、本記事ではその方法を十分な保護とは扱っていません。

根拠：判断の根拠となる公式情報

不審な変化がある場合は、更新とは別に調査を依頼する

見覚えのない管理者、意図しない書き換え、不審な転送などに気づいたら、症状・URL・発見日時・直前に行った変更を記録して、契約先や保守担当へ連絡します。表示障害だけで侵害とは断定しませんが、修正を適用したことだけで調査を終えることもしません。

根拠：WordPress.orgの被害が疑われる場合の案内

筆者がWordPress.comに今回の対応状況を確認した経緯は、「PHPの脆弱性を知った夜、WordPressを続ける理由」にまとめています。個別の回答は、そのサイトと確認時点についての記録として紹介しています。

06WordPressとPHP脆弱性のよくある質問

WordPress本体を最新版にすれば、今回のPHPの問題も直る？

本体の更新だけでは、直ったと判断できません。今回の修正対象はPHPです。WordPressの更新状況と、サーバー側のPHPへの対応を分けて確認してください。

WAFがあれば、PHPの更新は不要？

不要とはいえません。WAFなどの保護とPHPへの修正適用は別です。Automatticの公式解説も、暫定的な保護を修正の代わりにはしていません。提供元の修正案内に従ってください。

サイトヘルスに警告がなければ、対応済み？

警告の有無だけでは判断できません。10月21日の2件への修正が対象サイトに適用されているかを確認し、23日の追加条件は別に照合します。サイトヘルスの表示だけでは、実行中の保存形式変更の有無まで判断できません。

WordPress.comなら、今後も何もしなくてよい？

10月21日の保護案内を、23日の追加条件や今後のすべての問題へ広げることはできません。追加条件への該当性・対策は、提供元の追加告知や回答で確認します。WordPress.comの公式告知も、強いパスワードや2段階認証などのアカウント管理を勧めています。追加の案内が出たときは、その対象と必要な作業を確認します。

10月21日の修正版なら、23日の追加案内も対応済み？

それだけでは判断できません。CVE-2026-115560について、まれな対象構成に該当するか、必要な緩和策が適用されているかを管理者に確認します。すでにアップロード進捗を無効化していれば維持し、次の正式勧告・修正案内を確認してください。管理型サービスで一律に設定を変更する必要はありません。

別のサービスへ移れば解決する？

移行だけで解決と判断せず、現在の環境への対応を先に確認してください。移行先を選ぶときは、PHPの管理範囲、必要な機能、復旧方法、相談先を比較します。移行中の旧環境も、未対応のまま放置しないようにします。

07まとめ｜対象サイト・対応根拠・次の作業を記録する

まず運営形態を確かめ、10月21日の2件への修正と、23日の追加条件への該当性・緩和策を別々に確認します。分からない点は管理者へ問い合わせ、追加作業が必要なら手順に沿って進めましょう。

確認先：契約サービスと、PHPを管理する担当者を確かめます。
対応根拠：公式告知・表示情報・回答が、対象サイトに当てはまるか照合します。
次の作業：追加作業の有無と、未確認点を次に確かめる相手・予定を記録します。

最後に、次の記録へ分かったことをまとめます。未確認の欄が残る場合は、次に確認する相手と予定を決めておくと、対応が止まりにくくなります。

PHP対応確認記録

【対象】
サイトURL：
ホスティング契約先・サービス名：
PHPの管理者・担当窓口：
対象①：CVE-2026-109618／CVE-2026-109619（10月21日）
対象②：CVE-2026-115560（10月23日追加案内）

【確認した情報】
確認日時・タイムゾーン：
PHPの表示情報（不明でも可）：
表示を確認した場所：
公式告知URL・告知日：
自分の契約・サイトに適用されると判断した根拠：
問い合わせ番号・回答日時（問い合わせた場合）：
対象①の修正適用状況・根拠：
対象②の該当／非該当／未確認と、その根拠：
対象②の緩和策・適用確認（必要な場合）：
回答の要点：

【次の行動】
状況：追加作業不要の案内／修正適用済み／自分の作業が必要／対応中／未確認
暫定保護の内容（案内がある場合）：
自分がする作業・期限：
実施済みの作業・日時：
残っている不明点：
次に確認する相手・予定：
対象②の正式勧告・次回修正リリース後の確認方法：
緩和策を維持・見直す条件（提供元の案内）：