2026年10月21日、WordPress を動かしている PHP 本体に、深刻な脆弱性が2件公表されました。WordPress のプラグインやテーマではなく、その土台である PHP の問題です。PHP で動いているサイトは、WordPress かどうかに関係なく対象になります。
この記事では、何が起きたのかを公的機関の情報をもとに整理し、WordPress サイトを管理している立場で「何を確認すればよいか」を順番にまとめます。
補足: 本記事は 2026年10月28日時点の情報です。状況は更新されることがあるため、最新の内容は記事内でリンクしている JPCERT/CC の注意喚起などで確認してください。
何が起きたのか
要点は次のとおりです。
- 対象: PHP 本体（CVE-2026-109618・CVE-2026-109619）
- 影響: 認証なしで、外部から任意のコードを実行されるおそれがある
- 深刻度: CVSS v4.0 で 9.2（Critical）
- 修正版: 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35（2026年10月21日公開）
- PHP 8.1 以前: 公式の修正版は提供されない
- 悪用の状況: 悪用を試みる通信の観測が報告されており、米国 CISA は実際に悪用されている脆弱性の一覧に追加しています
補足: CVE（Common Vulnerabilities and Exposures）は、公表された脆弱性に付けられる世界共通の識別番号です。CVSS は脆弱性の深刻度を 0〜10 で表す指標で、9.0 以上は最も深刻な「Critical」に分類されます。
その後、別の脆弱性（CVE-2026-115560）も追加で公表され、JPCERT/CC の注意喚起に緩和策とあわせて追記されています。詳しくは JPCERT/CC の注意喚起 を参照してください。
PHP を更新するのは誰か
ここが WordPress のプラグイン更新と大きく違う点です。PHP はサーバー側の部品なので、サイトの管理画面からは更新できません。誰が更新するかは、サーバーの種類で変わります。
- 共用レンタルサーバー: サーバー会社が修正版を適用します。利用者側は、サーバー会社の告知で対応状況を確認し、必要に応じて管理画面で PHP のバージョンを切り替えます。
- VPS・専用サーバー・クラウド: PHP を入れた人（自分か、構築を担当した会社）が更新します。OS のパッケージ更新や、PHP のビルドし直しが必要です。
- マネージド WordPress ホスティング: 多くはホスティング会社が対応しますが、PHP のバージョン切り替えを利用者が選ぶ形のサービスもあります。
「サーバー会社がやってくれるはず」と思い込まず、自分のサイトがどれに当たるかをまず確認するのが出発点です。
確認すること
1. サーバー会社の告知を確認する
共用サーバーやマネージドホスティングなら、まずサーバー会社の告知を見ます。今回の件では、国内外の多くのサーバー会社が対応状況を公表しています。確認したいのは次の2点です。
- 修正版の適用が完了しているか（いつ完了したか）
- 利用者側で必要な作業があるか（PHP バージョンの切り替えなど）
2. サイトが実際に使っている PHP のバージョンを確認する
修正版かどうかは、パッチ番号まで見ないと判断できません。たとえば「8.3」系なら 8.3.36 以上が修正版で、8.3.35 以前は対象です。
確認の方法はいくつかあります。
- WordPress の管理画面: 「ツール」→「サイトヘルス」→「情報」タブ →「サーバー」で、PHP のバージョンが表示されます。
- WP-CLI: SSH でログインして
wp --infoを実行すると、PHP のバージョンが表示されます。
wp --info
補足: WP-CLI（
wp --info）が表示するのは、コマンドラインで動いている PHP のバージョンです。サーバーによっては、Web ページを表示している PHP とコマンドライン用の PHP が別になっていて、バージョンが違うことがあります。サイトの安全性に直接関わるのは Web 側の PHP なので、サイトヘルスの表示や、サーバー会社の管理画面の設定もあわせて確認してください。
管理しているサイトが多い場合は、サイトごとの PHP バージョンを一覧にして、修正版かどうかを並べて確認すると漏れを防げます。
3. PHP 8.1 以前のサイトは、バージョンの切り替えを検討する
PHP 8.1 以前には、今回の公式の修正版が提供されません。サポートが終了したバージョンのまま使い続ける限り、今後見つかる脆弱性にも修正が出ないということです。
PHP の各バージョンのサポート期限は、php.net のサポート状況のページ で確認できます。2026年10月時点で、8.2 のセキュリティサポートは 2026年12月31日までです。
バージョンを切り替えるときは、順番が大切です。
- バックアップを取る（ファイルとデータベースの両方）
- WordPress 本体・プラグイン・テーマを先に最新にする（新しい PHP への対応は、新しいバージョンで入っていることが多いため）
- PHP を切り替えて、表示と主要な機能を確認する（問題が出たら、元のバージョンに戻せるようにしておく）
PHP のバージョンアップで何が動かなくなりやすいかは、「PHPのバージョンアップで何が壊れるのか — 非推奨（deprecated）と削除（removed）の違い」で詳しく解説しています。
4. 不審な変化がないかを確認する
修正版の適用より前に攻撃を受けていた可能性もゼロではありません。サーバー会社や公的機関の案内に沿って、次のような点を確認してください。
- 身に覚えのないファイルや管理者ユーザーが増えていないか
- サイトの表示やリダイレクト先が意図せず変わっていないか
- サーバー会社から不正アクセスに関する連絡が来ていないか
不審な点が見つかった場合は、自己判断で作業を進めず、サーバー会社に相談するのが安全です。
「最新に保つ」を続けるために
今回は PHP 本体でしたが、脆弱性は WordPress 本体・プラグイン・テーマでも、ほぼ毎月のように公表されています。公表された脆弱性は、修正版が出たあとも、更新されていないサイトを狙って悪用が続きます。対策の基本は、修正版をできるだけ早く適用することです。
ただ、現場で更新が後回しになる一番の理由は、「更新でサイトが壊れるかもしれない」という不安です。この不安は、手順で小さくできます。
- 更新の前に、必ずバックアップを取る（戻せる状態を先に作る）
- まとめて更新せず、1件ずつ更新して、そのたびに表示を確認する（問題が出たときに原因を特定しやすくする）
- 何を、いつ、どのバージョンに更新したかを記録する（後から確認・説明できるようにする）
バックアップの考え方は「3-2-1バックアップルールとは何か — なぜ「3」なのか」、更新後の確認項目は「WordPress メジャーアップグレード後の動作確認 — 「更新完了」から「稼働確認」までの 7 ステップ」にまとめています。
当ブログを運営している WP メンテナンスマネージャーでも、各サイトの PHP バージョンを取得してサイト一覧で確認・絞り込みできるようにしています（PHP 本体の更新は、上で書いたとおりサーバー側で行うものです）。
まとめ
- 2026年10月21日、PHP 本体に深刻な脆弱性（CVE-2026-109618・CVE-2026-109619）が公表された。修正版は 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35。
- PHP 8.1 以前には公式の修正版が出ない。
- PHP はサーバー側の部品。共用サーバーならサーバー会社の告知を確認し、自分で管理するサーバーなら自分で更新する。
- 修正版かどうかは、パッチ番号まで確認する。WP-CLI の表示はコマンドライン側の PHP なので、Web 側の PHP もあわせて確認する。
- 古い PHP を切り替えるときは、バックアップ → WordPress・プラグイン・テーマの更新 → PHP の切り替え、の順で進める。
今回のような大きな脆弱性は、保守の大切さを改めて確認するきっかけにもなります。慌てずに、一つずつ確認していきましょう。
参考: JPCERT/CC 注意喚起 ／ JVN（JVNVU#99905564） ／ php.net 対応バージョン一覧