「PHPに重大な脆弱性」「サービスが緊急メンテナンス」。ニュースを見て、自社のWordPressも更新しておけばよいのか、と考えた方は多いと思います。ややこしいのは、「WordPressは最新版です」という返事だけでは、今回の対策が済んだか分からないことです。
2026年10月21日、PHPの開発チームは、認証なしで外部からコードを実行されるおそれのある2件の脆弱性について修正版を公開しました。対象はCVE-2026-109618とCVE-2026-109619。深刻度はいずれもCritical、CVSS v4.0の評価は9.2です。[1][2][3]
2026年10月22日確認。この記事はWordPressを利用する企業のサイト担当者向けです。各サーバーへの修正適用状況は随時変わるため、契約先の最新の告知と照合してください。
WordPressの「更新」と、PHPの修正は別の作業
PHPは、サーバーの中でWordPressを動かすためのプログラムです。普段、管理画面から記事を保存したり、お問い合わせを受け付けたりするときも働いています。WordPressの本体、テーマ、プラグインは、そのPHPの上で動きます。
今回問題になったのは、その土台であるPHPの内部処理です。「リモートコード実行（RCE）」とは、攻撃者が離れた場所から、サーバーで意図しないプログラムを動かせてしまうこと。管理画面のパスワードを知らなくても成立し得る問題なので、ログインを守る対策だけで解決したとは考えられません。
WordPress公式も、今回の問題を直すためのWordPress本体の更新は予定していない、と案内しています。[4] 「本体の更新通知が来ていないから関係ない」と読み飛ばしやすいところですが、確認先はサーバー側です。普段のWordPress・テーマ・プラグインの更新が不要になる、という意味ではありません。
まず、いま動いているPHPを確かめる
WordPressへ管理者でログインできる場合は、次の順に開きます。[4][5]
- 左のメニューから「ツール」→「サイトヘルス」を開く。
- ページ上部の「情報」に切り替える。
- 「サーバー」を開き、「PHP バージョン」を読む。
見るのは「WordPressのバージョン」ではなく、「サーバー」の中にあるPHPの番号です。管理者権限がない、項目が見当たらない場合は、保守会社やサーバーの管理者に、そのサイトをWebで動かしているPHPを確認してもらいます。
サーバー内にPHPが複数入っている環境では、保守担当者がコマンドで調べたPHPと、サイトが使うPHPが異なる場合もあります。対象のドメインと、いま見た画面の番号を一緒に伝えると、確認する環境の取り違えを減らせます。
「PHP 8だから大丈夫」でも、判断できない
PHP公式が今回の2件を修正した版として公開したのは、次の番号です。例えば8.3系なら8.3.35ではなく、8.3.36が今回の修正版です。小数点の後ろまで確認してください。[1]
| 使っている系列 | 今回の公式修正版 |
|---|---|
| PHP 8.5系 | 8.5.12 |
| PHP 8.4系 | 8.4.27 |
| PHP 8.3系 | 8.3.36 |
| PHP 8.2系 | 8.2.35 |
ただし、ここには一つ例外があります。Linuxの配布元やサーバー会社が、今のPHPへ修正部分だけを取り込む「バックポート」という対応を行うことがあります。その場合、画面の番号だけでは修正の有無を判定できません。提供元が今回の二つのCVEに対応済みと案内しているかも確認します。[1]
PHP 8.1以前はPHPプロジェクトの通常のセキュリティサポートが終了しています。今回は7.4・8.0・8.1向けに最小限のソース修正も用意されましたが、利用中のサーバーへ自動で入るという意味ではありません。提供元の対応を確認し、並行してサポートされる系列への移行を進める必要があります。[1]
逆に、ニュースを読んですぐ、互換性を確かめずに8.1から8.5へ切り替えるのも別のトラブルのもとです。まず今回の修正を適用する方法を管理者と詰め、系列を上げるならテーマ・プラグインの対応状況と復旧方法も確かめます。
レンタルサーバーなら、誰が対応する？
共用レンタルサーバーでは、PHP自体の修正適用をサーバー会社が行うことが多く、サイト担当者がPHPのファイルを自分で置き換える作業ではありません。一方、どの系列を使うかの変更や、更新後のサイトの確認を、利用者側へ求める場合があります。[4] VPSや自社管理のサーバーなら、自社または委託先のサーバー管理者が更新を担います。
10月21日のエックスサーバー停止は、何を止めたのか
同社が10月21日16時から行ったのは、予防的な安全対策としての一時停止です。管理画面が突然開かなくなると、攻撃を受けたのかと心配になりますが、告知は次のように説明しています。[6]
不正アクセスの発生に伴うものではございません。
同社は、10月22日1時10分時点の告知で、8.2〜8.5への修正適用を順次開始し、古い系列は独自修正の作成に着手したと説明しています。[6] これはその時点の進捗で、全サーバーの完了を示すものではありません。
同じ告知では、公式サイト・管理画面などの一時停止と、契約者のWebサイト・メールの稼働継続を分けて案内しています。ここは丁寧に読みたいところです。「サイトが表示されていること」「管理画面が再開したこと」「自分の環境にPHPの修正が入ったこと」は、それぞれ別の確認です。停止を見て情報漏えいが起きたと決めつけることも、表示されているから対策済みだと考えることもできません。
契約先の告知で、利用中のPHPの系列が対象か、適用完了まで書かれているか、利用者の追加作業があるかを読みます。「対応中」までしか分からなければ、修正適用を確認できる状態と区別して保守担当者へ共有します。別サービス向けのお知らせを、自社の契約にそのまま当てはめないことも大切です。
修正をすぐ適用できないときは
PHPの公式アドバイザリは、設定変更などの緩和策だけで安全になったとはいえず、完全な修正を含む版への更新が必要だと説明しています。[3] WAF（不審なWebリクエストを遮る仕組み）があることや、WordPressにメンテナンス画面を出したことだけで、対応完了にはできません。
今回、アプリケーションのコードが動く前に攻撃が成立する構成も確認されています。[2] WordPressの中で見せ方を変える対策では、その前段のPHPの問題を解決したことにならないためです。
英国NCSCは、PHPを使う環境を洗い出し、外部公開されたシステムを優先するよう求めています。更新や適切な緩和策をすぐ適用できない場合は、一時的な公開停止も検討するよう案内しています。[7] 修正適用が確認できない状態では、サーバー管理者と、外部からのアクセス制限や一時停止の必要性を早急に判断する段階です。手順の意味が分からないまま、SNSの設定例を本番へコピーする場面ではありません。
修正が入ったら、問い合わせまで一度通す
提供元または管理者に修正適用を確認できたら、トップだけでなく、記事、管理画面へのログイン、お問い合わせなど、事業で使う動線を確認します。フォームは送信完了の表示だけで終えず、動作確認と分かる内容で通知・自動返信まで確かめると、更新後に受付が止まっている状態を見落としにくくなります。
更新した日、対象ドメイン、PHPの番号、修正適用の根拠となる提供元の告知や回答を残します。バックポート対応なら、番号が変わらなくても、何を根拠に確認したかが次の担当者へ伝わります。更新前から不審な変更やログインなどの兆候がある場合は、更新だけで過去の侵入まで解決したと考えず、保守担当者の調査も必要です。
広告や広報の仕事では、サイトが開けば「いつもどおり」に見えます。けれど、今回のニュースで確認したいのは、その受け皿を動かすPHPに修正が入ったかどうかです。「最新版にしました」という一言を、どのプログラムの、どの修正まで済んだかに具体化する。サイトの専門家でなくても、そこは担当者同士で確かめられます。
根拠・参考資料と、確認時点
出典確認日：2026年10月22日。PHP・WordPressの公式発表、公式ドキュメント、サーバー提供元とNCSCの注意喚起を照合しました。サーバー会社の進捗は本文に記した時点のものです。個別サイトへの修正適用を保証する記事ではありません。図はHYPEUP編集部が作成、画面はローカル検証環境で撮影しました。
[1] PHP公式：2026年10月21日のセキュリティ勧告
[2] PHP公式アドバイザリ：CVE-2026-109618
[3] PHP公式アドバイザリ：CVE-2026-109619
[4] WordPress公式：Critical PHP Security Release
[5] WordPress公式ドキュメント：Site Health screen
