実際に悪用が確認されている脆弱性（CISA KEV掲載）の速報解説です。何が起きるのか・影響範囲・対応策を、攻撃の再現手順は伏せて防御目線でまとめます。
- CVE
- CVE-2026-87902（GHSA-7hp8-65ch-5whp）
- 重大度
- NVD：CVSS v3.1 8.1（攻撃条件の複雑さ＝高）／公式アドバイザリ：CVSS v4.0 9.2・Critical
- 種別
- ファイルインクルード（CWE-98）。ページテンプレート解決処理のパス・トラバーサル
- 影響
- テーマ外の .php ファイルの読み込み。テーマとサーバー設定の条件がそろうとRCE
- 前提条件
- 認証不要・利用者の操作不要
- 対象
- WordPress 4.7.0〜7.1.1
- 修正
- 2026年9月22日公開の 7.1.2。4.7系まで各系列に修正を提供
- 悪用状況
- CISA KEV 掲載（2026年9月25日追加・是正期限 9月28日）。フォレンジックのトリアージが求められる対象として掲載
放置の危険度
WordPressは最も広く使われているCMSで、今回の対象は約10年分のバージョンに及びます。認証も利用者の操作も要りません。WordPress向けのセキュリティ企業は、修正の公開当日から探索が始まり、翌日にはコード実行を狙う試行に移り、汎用の走査ツールにも組み込まれたと報告しています。無差別に走査されるので、サイトの規模は関係ありません。
どんな脆弱性か
WordPressは、表示するページに応じて「どのテンプレートファイルを使うか」をテーマのディレクトリから探して決めます。公式アドバイザリによれば、このページテンプレートの解決処理に抜けがあり、認証されていない攻撃者が、有効なテーマのディレクトリの外にある .php ファイルを読み込ませることができました。外部から渡された値で「読み込むファイル」が決まってしまう。これがファイルインクルード（CWE-98）です。当サイトは具体的な悪用方法を記載しません。
ただし、それだけではコード実行になりません。公式アドバイザリは、RCEに至る条件をテーマ側とサーバー側の2つに分けて説明しています。
テーマ側の条件（公式アドバイザリより）
- 有効な親テーマまたは子テーマの直下に、名前が
page-で始まるディレクトリ（例：page-templates）がある - アドバイザリは、公式の旧テーマ Twenty Twelve・Twenty Fourteen と、Neve・Hestia・Sydney など広く使われるテーマの一部が該当するとしている（テーマ側の欠陥ではなく、本体の処理の問題）
サーバー側の条件（公式アドバイザリより）
- 読み込ませると危険な動作をする .php ファイルが、サーバー上にWebサーバーの権限で読める状態で存在する
- PHPの
register_argc_argvが有効だと、この条件が成立しやすい - アドバイザリは、公式のPHP Dockerイメージと、PHP 8.5 未満を使う cPanel の既定構成が該当するとしている
① 本体の欠陥：テーマ外の .php を読み込ませられる
→ 7.1.2（各系列の修正版）で解消
② テーマの条件：page- で始まるディレクトリがある
→ 自分では把握しにくい。判定に頼らない
③ サーバーの条件：危険な .php が読めて、register_argc_argv が有効
→ 設定を無効化すれば、同じ型の攻撃をまとめて防げる
影響範囲
| 系列 | 影響を受けるバージョン | 修正版 |
|---|---|---|
| 7.1 | 7.1.0〜7.1.1 | 7.1.2 |
| 7.0 | 7.0.0〜7.0.5 | 7.0.6 |
| 6.9 | 6.9.0〜6.9.8 | 6.9.9 |
| 6.8 | 6.8.0〜6.8.9 | 6.8.10 |
| 6.7〜4.7 | 各系列の最新の1つ前まで | 各系列の修正版（6.7.9 … 4.7.37） |
| 4.7より前 | — | 修正なし（サポート外） |
対応策
現在のバージョンを確認し、修正版に上げる（最優先）
管理画面の「ダッシュボード → 更新」で、今のバージョンを確認します。7.1.2（または自分の系列の修正版）でなければ、今日更新してください。WordPressは最新版だけを正式サポートとしているので、可能なら 7.1.2 に上げるのが確実です。
「自動更新が届かない」サイトを洗い出す
自動のバックグラウンド更新に対応したサイトでは、更新は自動で始まります。危ないのはそこから外れているサイトです。具体的には、自動更新を無効にしている、Gitやコンテナイメージでコアのバージョンを固定している（更新してもイメージを作り直すと古い版に戻る）、ホスティング側で更新を止めている、そして存在を忘れている古いサイト。複数のサイトを持っているなら、1つずつ確認します（資産棚卸しチェックリスト）。
PHPの register_argc_argv を無効にする（多層防御）
Webサーバーで動くPHPが、この設定を必要とすることはほとんどありません。php.ini（またはホスティングのPHP設定画面）で register_argc_argv = Off にします。コンテナで動かしている場合は、イメージ側の設定を確認してください。更新の代わりにはなりませんが、今回の脆弱性に限らず、ファイルインクルードをコード実行につなげる経路をまとめてなくせます。
更新前に入られていないかを確認する
9月22日以降も未更新だった期間があるなら、その間を疑います。CISAもこのCVEをフォレンジックのトリアージ対象としています。最低限、①/tmp や /var/tmp、wp-content 配下に見覚えのない .php ファイルがないか、②アクセスログに、パーセントエンコードされたディレクトリ移動（../ に相当する文字列）を含むリクエストがないか、③見覚えのない管理者ユーザーや、最近追加されたプラグインがないかを確認します。
怪しい点があれば、更新だけで終わらせない
コード実行を許した可能性があるなら、パッチを当ててもすでに置かれたファイルや盗まれた鍵は残ります。wp-config.php のデータベースパスワードと認証キー（ソルト）、管理者パスワード、外部サービスのAPIキーを入れ替え、不審なファイルを除去します。手順の全体像は 脆弱性対応の実務手順 と WordPressのセキュリティ対策 にまとめています。
当サイトの視点：修正が公開されると、すぐに攻撃も始まる
先日の Adobe Commerce の件 では、修正からKEV入りまで44日ありました。今回は3日です。違いは、修正の差分を読めば攻撃を組み立てられることと、利用者の数です。報告によれば、修正が出た当日のうちに、差分と同じ形の探索が始まっていました。
ここから言えるのは、広く使われる製品では、修正が公開された時点から攻撃者も動き出し、更新までの余裕はないということです。そして、それに人の手で毎回間に合わせるのは難しい。だから当サイトは、自動更新が確実に届く状態を保つことを、パッチ運用そのものより上に置いています。今回、自動更新が届いていたサイトは、運営者が何も知らないうちに対応が済んでいたはずです。危ないのは、自動更新の外にいることに気づいていないサイトです。
もう1つ。EPSSは3%でした。EPSSは便利な指標ですが、公開直後の脆弱性では実態に遅れます。KEVとEPSSが食い違うときは、確認された事実であるKEVを優先してください。
出典
- WordPress — GHSA-7hp8-65ch-5whp（影響バージョン・修正版・RCEの前提条件・CVSS v4.0 9.2）
- WordPress.org — WordPress 7.1.2 Release（2026年9月22日。4.7系までのバックポート、自動更新）
- NVD — CVE-2026-87902（CWE-98／CVSS v3.1 8.1）
- CISA KEV — Known Exploited Vulnerabilities Catalog（2026年9月25日追加・是正期限 9月28日・フォレンジックのトリアージ対象）
- FIRST — EPSS（2026年9月25日時点 0.029）
- 観測報告 — Patchstack（修正公開当日からの探索と、翌日のコード実行の試行。本記事は時系列と防御側の確認点のみを参照）