WordPress 7.1.2で修正された脆弱性CVE-2026-87902の影響確認と対応手順

CVE-2026-87902とは、WordPress 4.7.0〜7.1.1の本体に見つかった脆弱性で、ログインしていない第三者が、使用中のテーマのフォルダの外にあるPHPファイルを読み込ませられるものです。2026年9月22日公開のWordPress 7.1.2（と古い系統の修正版）で修正されており、WordPress公式はすぐに更新するよう呼びかけています。

この脆弱性は、修正版が公開された当日から攻撃の試行が観測されています。自動更新で修正版になっているサイトも多い一方で、サーバーの設定によっては自動更新が働かず、古いバージョンのまま動いているサイトもあります。「自分のサイトは大丈夫なのか」「更新する前に狙われていないか」は、いくつかの確認で判断できます。

この記事では、CVE-2026-87902の内容と、自分のサイトが対象かを判定する方法、今すぐできる対応、更新前に狙われていないかの確認ポイント、侵害が疑われるときの初動を、WordPress公式の情報をもとに整理します。攻撃の具体的な手順は載せていません。記載の内容は2026年10月6日時点の情報です。

CVE-2026-87902とは？影響範囲と深刻度

CVE-2026-87902は、WordPressがページの表示に使うテンプレートファイルを選ぶ処理の不備です。URLに細工した値を渡すと、本来はテーマのフォルダの中からしか選ばれないはずのテンプレートとして、テーマ外にあるPHPファイルが読み込まれます。WordPress公式のセキュリティアドバイザリ（GHSA-7hp8-65ch-5whp）によると、ログインは不要です。プラグインではなくWordPress本体の問題なので、プラグインを入れていないサイトも対象になります。

深刻度の数値が2つあるのは、評価に使っている規格の版が違うためで、どちらも正しい値です。WordPress公式はCVSS 4.0で9.2、米国の脆弱性データベースNVDに掲載されたCISAの評価と日本のJVN iPediaはCVSS 3.1で8.1と評価しています。JPCERT/CCも2026年9月30日のWeekly Reportで「特定の構成でWordPressを使用している場合、遠隔の第三者が認証不要でコードを実行する可能性があります。」と注意を呼びかけています。

攻撃はすでに始まっています。WordPress向けのセキュリティ企業Patchstackは、7.1.2が公開された9月22日のうちに最初の攻撃の試行を観測したと報告しています。CrowdSecの観測では、2026年9月23日以降、30,813の異なるIPアドレスから該当する攻撃リクエストが送られていました（2026年9月28日時点の数値）。修正版の公開と同時に狙われ始めたと考えて、早めに確認するのが安全です。

自分のサイトが対象か確認する方法

対象かどうかは、WordPress本体のバージョンで判定できます。使っているバージョンが4.7.0〜7.1.1の範囲にあり、下の表の修正版より古ければ対象です。

管理画面でバージョンを確認する

1. WordPressの管理画面にログインする
2. 左メニューの「ダッシュボード」→「更新」を開く
3. 画面上部に表示される現在のバージョンを確認する（管理画面の右下にもバージョンが表示されます）

WP-CLIでバージョンを確認する

サーバーにSSHで入れる場合や、複数のサイトをまとめて確認したい場合は、WP-CLIのコマンドが早いです。WordPressをインストールしたディレクトリで実行します。

# WordPress本体のバージョンを表示する
wp core version

系統ごとの修正版

WordPressは最新の7.1系だけでなく、古い系統にも修正版を出しています。使っている系統の修正版か、それより新しいバージョンになっていれば修正済みです（出典：WordPress公式アドバイザリ）。

4.6以前のバージョンには修正版が出ていません。WordPress公式は「積極的にサポートしているのは最新版のみ」としているため、4.6以前を使っている場合は最新版への移行が必要です。古い系統の修正版も、最新版へ上げるまでのつなぎと考えるのが現実的です。

PHPの実行までつながる2つの条件

テーマ外のファイルを読み込ませる穴そのものは対象バージョンすべてにありますが、サーバー上でプログラムを実行されるところまで進むのは、次の2つがそろったときです。WordPress公式アドバイザリに書かれている前提条件を整理しました。

テーマのフォルダを確認する

条件の1つ目は、テーマのフォルダを見れば判定できます。SSHで入れる場合は、WordPressをインストールしたディレクトリで次のコマンドを実行します。何も表示されなければ、1つ目の条件には当てはまりません。

# テーマ直下にある「page-」で始まるフォルダを一覧する
ls -d wp-content/themes/*/page-*/

注意したいのは、条件になっているのはフォルダだということです。page.phpやpage-about.phpのような、「page-」で始まるテンプレートファイルは条件に当たりません。FTPソフトやレンタルサーバーのファイルマネージャーで見る場合も、フォルダかファイルかを区別して確認してください。

条件に当てはまらなくても更新は必要

2つの条件は、いま知られている「プログラムの実行まで進む経路」の話です。テーマ外のファイルを読み込ませる穴自体は、条件に関係なく残っています。条件の判定は、どれくらい急いで動くかを決める材料に使い、更新しない理由にはしないでください。

今すぐできる対応チェックポイント

対応の中心は、修正版への更新と、自動更新がきちんと働いているかの確認です。上から順に進めてください。

自動更新が有効でも確認したほうがいい理由

WordPressは3.7以降、セキュリティ更新を自動で適用するのが既定の動きです。7.1.2のリリース告知でも「自動バックグラウンド更新に対応したサイトでは、更新が自動で始まる」とされています。

ただし、WordPress公式のドキュメントによると、自動更新が働くのは、ファイルの所有権の関係でFTPの接続情報なしに更新できる環境で、Gitなどのバージョン管理で本体を管理しておらず、自動更新を無効にしていない場合です。どれかに当てはまると、修正版が出ても古いバージョンのまま動き続けます。公式は自動更新の無効化を「強く非推奨」としているので、無効にしている理由が特になければ有効に戻すことを検討してください。

すぐ更新できないときの一時対応

テーマやプラグインの互換性の確認が必要で、すぐには更新できないこともあります。Patchstackは、そうした場合の一時対応として、WAF（Webアプリケーションファイアウォール）でpagenameに「../」にあたる値が入ったリクエストを遮断することを勧めています。また、PHPのregister_argc_argvをOffにするとpearcmd.phpを使った経路は止まりますが、テーマ外のファイルを読み込む動き自体は止まらないとしています。

WAFのルールは、値の書き方を変えた攻撃をすべて防げるとは限りません。一時対応は更新までのつなぎで、根本の対策は修正版への更新です。

更新前に狙われていないかの確認ポイント

修正版の公開と同じ日に攻撃が始まっているため、更新したあとも、更新前に入り込まれていないかを確認しておくと安心です。WordPress公式は侵害の痕跡を公表していないため、ここでは実際の攻撃を観測したPatchstackの報告とWordPress公式のツールをもとに、一般的な点検項目を加えて確認ポイントをまとめました。

アクセスログを検索する

アクセスログの場所はサーバーによって違います。レンタルサーバーの場合は、管理画面からログをダウンロードできることが多いです。ダウンロードしたログに対して、次のように検索します。

# pagename に「../」を変換した値が入ったリクエストを探す
grep -Ei 'pagename=[^ ]*%(25)?2e' access.log

# pearcmd や config-create を含むリクエストを探す
grep -Ei 'pearcmd|config-create' access.log

該当するリクエストが見つかっても、それだけで侵害されたとは限りません。こうした攻撃は、WordPressで作られたサイトに無差別に送られています。テーマの条件に当てはまらないサイトや、すでに更新済みのサイトでは失敗しているはずなので、ほかの確認ポイントと合わせて判断してください。

本体のファイルと最近の変更を確認する

WP-CLIが使える場合は、wp core verify-checksumsで、WordPress本体のファイルが公式の配布ファイルと一致しているかを確認できます。このコマンドが調べるのは本体だけなので、テーマやプラグイン、アップロードフォルダは更新日時で確認します。

# WordPress本体のファイルが公式と一致するか確認する
wp core verify-checksums

# 2026年9月20日以降に変更されたPHPファイルを一覧する
find wp-content -name '*.php' -newermt '2026-09-20'

# 一時フォルダにPHPファイルがないか確認する
find /tmp /var/tmp -name '*.php' 2>/dev/null

プラグインやテーマの更新でもファイルの日時は変わります。一覧に出たファイルが、自分で更新したものかどうかを見比べてください。

侵害が疑われるときの初動

侵害の跡が見つかったら、ファイルを消したり上書きしたりする前に、まず記録を残します。WordPress公式の「My site was hacked」で示されている手順を、順番どおりに整理しました。

1. 気づいた日時、症状、見つけたファイルやログを記録する
2. サイトと、管理に使っている手元のパソコンをウイルススキャンする
3. レンタルサーバーなどのホスティング事業者に連絡し、サーバー側で検知されていないかを確認する
4. すべてのユーザーのパスワードを変更し、wp-config.phpの認証用キー（ソルト）を作り直す
5. バックアップを取る。原因を調べるために、侵害された状態のコピーも別に残しておく
6. wp-adminとwp-includesを同じバージョンの公式ファイルで入れ替え、.htaccessに覚えのない記述がないかを確認する
7. きれいにしたあとで修正版へ更新し、パスワードをもう一度変更する
8. 侵入された経路を調べ、同じ経路を使われないように設定を見直す

自分だけで判断できない場合は、ホスティング事業者や、WordPressの保守を扱っている専門の業者に相談してください。侵害された状態のコピーを消さずに残しておくと、あとで原因を特定するときに役立ちます。

会員情報や問い合わせの内容など、利用者の個人情報が漏れた可能性がある場合は、利用者への案内も必要になります。利用者の側で何を確認し、どんな連絡に気をつければよいかは、RINIAの「個人情報漏洩の対策」でまとめています。案内文を書くときの参考にしてください。

当サイトで確認した結果

当サイト（codequest.work）もWordPressで運営しているため、2026年10月6日に、この記事の手順で確認しました。

確認して気づいたのは、テーマの中に「page-」で始まる名前のものがあっても、それがテンプレートファイルなら条件に当たらないという点です。当サイトのテーマにも「page-」で始まるテンプレートファイルはありますが、フォルダはありませんでした。ファイル名だけを見て慌てず、フォルダかどうかを確かめてください。

次の一手：予防と検知の仕組みを整える

今回の対応は「脆弱性が見つかったあと」の対応です。次の脆弱性に備えるには、入り込まれにくくする初期設定と、異変に早く気づくための監視の2つを整えておくのが効果的です。

ログイン周りの強化やバックアップの二重化といった予防の設定は、WordPress案件を受注したら最初にやるサーバー設定で、受注直後にやる順番どおりにまとめています。改ざんやサイトの停止にすぐ気づくための外形監視は、Web制作者のためのSRE入門｜無料の外形監視とSLOの決め方で、無料で始められる方法を紹介しています。

テーマ開発からサーバー構築、運用まで、WordPressの記事をまとめて読みたい場合はWordPress実践ガイドから目的の記事を探せます。

よくある質問

Q. 自動更新を有効にしていれば、何もしなくても大丈夫ですか？

多くのサイトでは、自動更新で7.1.2や各系統の修正版に上がっています。ただし、FTPの接続情報が必要なサーバー設定や、自動更新を無効にする設定があると適用されません。管理画面かwp core versionで、修正版になっているかを一度確認してください。

Q. WordPress 4.6以前を使っている場合はどうすればいいですか？

4.6以前には修正版が出ていないため、最新版への移行が必要です。テーマやプラグインが新しいバージョンで動くかをテスト環境で確かめてから、本番を更新してください。

Q. プラグインの脆弱性とは違うのですか？

違います。CVE-2026-87902はWordPress本体の脆弱性なので、プラグインを1つも入れていないサイトも対象です。対応も、プラグインではなくWordPress本体の更新になります。

Q. テーマに「page-」で始まるフォルダがなければ、更新しなくてもいいですか？

更新は必要です。フォルダがなければ、いま知られている「プログラムの実行まで進む経路」には当てはまりませんが、テーマ外のファイルを読み込ませる穴そのものは残っています。

Q. アクセスログに攻撃らしきリクエストがあったら、侵害されているということですか？

それだけでは判断できません。この攻撃はWordPressのサイトに無差別に送られていて、条件に当てはまらないサイトや更新済みのサイトでは失敗します。本体ファイルの検証、管理者ユーザー、最近変わったファイルと合わせて判断してください。

Q. WAFやセキュリティプラグインを入れていれば安全ですか？

更新までの間、攻撃を減らす助けにはなります。ただ、値の書き方を変えた攻撃をすべて防げるとは限らないため、根本の対策は修正版への更新です。

関連記事

• WordPress案件を受注したら最初にやるサーバー設定
• WordPress実践ガイド【テーマ開発・CF7・サーバー構築まで全20記事】
• Web制作者のためのSRE入門｜無料の外形監視とSLOの決め方
• WordPressで「データベース接続エラー」が出たときの対処法｜破損が原因の場合の修復ガイド