2026年9月22日、WordPress は本体（WordPress Core）に深刻な脆弱性があるとして修正版 7.1.2 を公開しました。あわせて、セキュリティ修正の対象になっている古い系列すべて、いちばん古いものでは 4.7 系まで遡って修正版が出ています。プラグインやテーマではなく本体の問題なので、構成に関係なく全サイトが対象です。

まず確認するのは本体のバージョンだけです。管理画面の「ダッシュボード → 更新」を開いて、下の表の数字より古ければ、今日のうちに更新してください。

何が起きたのか

公式の説明では、認証を受けていない第三者が、一定の条件下で、ページのテンプレートを決める処理に「有効なテーマのディレクトリの外にある、読み取り可能な PHP ファイル」を読み込ませられるというものです。種類としては PHP リモートファイルインクルージョン（CWE-98）にあたります。

• CVE 番号 … CVE-2026-87902（GHSA-7hp8-65ch-5whp）
• 影響を受けるバージョン … 4.7.0 から 7.1.1 まで
• 深刻度 … CVSS 4.0 で 9.2（緊急）、CVSS 3.1 で 8.1（重要）
• ログインの要否 … 不要。管理者の操作も、脆弱なプラグインも要りません

「読み込ませられる」だけで止まるか、そこから任意のコードを実行されるところまで行くかは、サーバーとテーマの状態で変わります。発見者は、実行まで至る条件として次のようなものを挙げています。

• 公開済みのページがあり、外部から指定できる状態になっている
• そのページに固定のテンプレートが割り当てられていない
• 有効なテーマ（親テーマ・子テーマのどちらでも）の最上位に、page- で始まる名前のディレクトリがある
• サーバー上に、Web サーバーの権限で読める .php ファイルが置かれている
• ファイルシステム側がその読み込みを許している

3番目の条件は、Twenty Twelve や Twenty Fourteen といった公式テーマ、Neve・Hestia・Sydney などの配布テーマが該当します。page-templates のような空のディレクトリでも条件を満たします。「自分のテーマは関係ない」と当たりをつけて更新を見送る判断は、やめたほうがよい部分です。

サーバー側では、PHP の register_argc_argv が有効になっていると、サーバーに元から入っている PEAR の pearcmd.php を踏み台にされやすくなります。公式の PHP の Docker イメージや、cPanel の既定の設定がこれにあたる環境があります。

上げるべきバージョン

使っている系列ごとに修正版が出ています。7 系に上げなくても、同じ系列の修正版に上げれば今回の穴はふさがります。

5 系以前にも同じように修正版が出ています（5.9.18 / 5.8.17 / 5.7.19 / 5.6.21 / 5.5.22 / 5.4.23 / 5.3.25 / 5.2.28 / 5.1.26 / 5.0.29 / 4.9.33 / 4.8.32 / 4.7.37）。4.6 以前はセキュリティ修正の対象外で、修正版はありません。4.7 以上に上げる以外に手がありません。

4.7 は 2016年末のバージョンです。そこまで修正を出したというのは、それだけ放置できない内容だったということです。

自動更新が効いていても、確認は要る

WordPress は 3.7 以降、マイナーリリース（x.y.z の z が上がる更新）を既定で自動的に当てます。今回は各系列に修正版が出ているので、自動更新が生きているサイトはすでに当たっている可能性が高いです。

ただし、自動更新が止まっている現場は珍しくありません。

• wp-config.php で WP_AUTO_UPDATE_CORE を false にしている
• ファイルの所有者や権限の都合で、本体を書き換えられない
• 本体のファイルを直接書き換えてあり、更新が当たらない（当てると改変が消える）
• レンタルサーバー側の管理機能で更新を止めている
• 制作会社や担当者が「壊れると困るから」と切ったまま引き継がれている

どれも管理画面を見れば分かります。ダッシュボードの「更新」を開いて、今のバージョンが上の表の数字に届いているかだけ見てください。届いていなければ、その場で更新できます。

すでに狙われていなかったか調べる

今回は、修正版の公開と攻撃の開始がほぼ同時でした。経緯は次のとおりです。

• 2026年7月20日 … 発見者が HackerOne 経由で WordPress に報告
• 2026年9月22日 … 修正版が公開。同日に検証コードも公開され、同日 11時49分（UTC）には最初の試行が観測される
• 2026年9月23日 … 試し打ちから、サーバーにファイルを書き込もうとする段階へ
• 2026年9月25日 … 米国 CISA が悪用が確認された脆弱性の一覧（KEV）に追加。連邦機関には9月28日までの対処を要求
• 2026年9月29日 … JVN iPedia に登録（JVNDB-2026-035982）
• 2026年9月30日 … JPCERT/CC の Weekly Report に掲載

集計では、9月23日以降の数日で3万を超える送信元 IP からの試行が観測されています。狙われた形跡があるかどうかは、次を見ます。

• サーバーの /tmp と /var/tmp に、見覚えのない .php ファイルが無いか
• アクセスログに、クエリ文字列へ上位ディレクトリへ戻る並び（.. を URL エンコードしたもの）が混ざったリクエストが無いか
• 普通のページの URL を要求したのに、RSS や OPML が返っている記録が無いか
• wp-content/uploads の中に .php ファイルが無いか（本来ここに PHP は要りません）
• 管理者ユーザーの一覧に、知らないユーザーが増えていないか

/tmp や /var/tmp に .php が書かれていた場合、「スキャンされた」ではなく「書き込みが成立した」状態です。更新して終わりにせず、入られた前提での対応に切り替えてください。

更新して壊れるのが怖い場合

今回の修正は同じ系列内のマイナーリリースで、機能の追加や画面の変更は入りません。プラグインの大型更新と違って、当てて表示が崩れる確率は低いほうです。それでも不安なら順番はこうです。

1. ファイルとデータベースのバックアップを取る（復元まで試せるなら試す）
2. 本体を更新する
3. トップ・固定ページ・問い合わせフォーム・会員系の画面を順に開いて表示を確認する
4. エラーログを見て、更新後に新しい警告が出ていないか確認する

「怖いので止めておく」は、今回については選びにくい判断です。悪用がすでに観測されていて、ログインも要らない種類の穴なので、放置している時間がそのまま危険な時間になります。

なお、更新が怖い状態そのものに原因があることも多いです。本体やプラグインを直接書き換えている、テーマの元ファイルが手元に無い、PHP が古くて上げると動かない、といった事情があると、脆弱性が出るたび毎回この判断で止まります。

次に同じことが起きたときのために

• 本体のマイナーリリースの自動更新は切らない。切る必要がある状態なら、その理由のほうを直す
• 使っていないテーマとプラグインは、無効化ではなく削除する
• PHP のバージョンとサーバーの設定を、年に一度は見る
• バックアップは「取れているか」ではなく「戻せるか」を一度試しておく
• 公式の発表（WordPress.org の News）や JPCERT/CC の Weekly Report を、誰が見るか決めておく

当社では、更新を止めずに運用できる形への作り直しと、保守をお引き受けしています。今回の件で自社サイトの状態が分からない、更新して問題が出た、という単発のご相談にも対応しています。