CVE-2026-87902とは、WordPress本体（コア）に見つかった重大な脆弱性で、ログインしていない第三者が任意のPHPファイルを読み込ませ、条件がそろえばサイトを乗っ取れるものです。2026年9月22日に修正版のWordPress 7.1.2が公開され、9月24日にはエックスサーバーからも利用者向けの注意喚起が出ました。影響範囲は4.7.0から7.1.1までのすべてのバージョンで、9月17日に出たばかりの7.1.1も対象です。この記事では、何が起きているのか、自分のサイトが対象かどうかの確認方法、更新の手順、すぐに更新できないときの応急対処、すでに攻撃されていないかを調べる方法までをまとめます。
CVE-2026-87902とは？何が起きているのか
結論から言うと、今回の脆弱性は「WordPress本体の不具合」であり、プラグインやテーマの問題ではありません。特定のプラグインを入れていないから無関係、という話ではなく、該当バージョンのWordPressを使っているすべてのサイトが更新の対象になります。
ログイン不要でPHPファイルを読み込ませる「パストラバーサル」
問題があったのは、WordPressが固定ページを表示するときに「どのテンプレートファイルを使うか」を決める処理です。具体的には wp-includes/template.php 内の get_page_template() で、URLから受け取った pagename の値をもとにテンプレートのファイル名を組み立てていました。ここで「..」のような上位ディレクトリへ移動する文字列の検査が抜けていたため、テーマフォルダの外にあるPHPファイルを指定して読み込ませることができました。この手口を「パストラバーサル（ディレクトリトラバーサル）」と呼びます。
読み込ませるファイルの中身次第では、攻撃者が用意した命令をサーバー上で実行させることができます。これが「リモートコード実行（RCE）」で、脆弱性の中でも最も深刻な部類です。今回はログインや管理者権限を一切必要としないため、誰でも外から試せる点が厄介です。
深刻度はCVSS 9.2の「Critical（緊急）」
脆弱性の深刻度を示すCVSS（v4.0）のスコアは9.2で、4段階のうち最も高い「Critical」に分類されています。WordPress公式も「セキュリティリリースなので、直ちにサイトを更新することを推奨する」と明記しています。報告者はセキュリティ研究者のRobert Ressl氏で、GitHubのアドバイザリ番号はGHSA-7hp8-65ch-5whpです。
修正版の公開当日から攻撃が始まっている
今回の脆弱性が「今すぐ動くべき案件」である最大の理由は、攻撃がすでに始まっていることです。セキュリティ企業Patchstackの観測では、修正版が公開された9月22日のうちに脆弱性を突く試行が確認され（協定世界時11時49分、日本時間の同日20時49分ごろ）、その約4時間後にはサーバーへファイルを書き込もうとする試行も見つかりました。翌23日には攻撃の通信量が初日の10倍以上に増え、脆弱なサイトを自動で探すスキャンツールも出回っています。
つまり「修正版が出たから安心」ではなく、「修正版が出たことで攻撃者にも手口が知れ渡った」と考えるのが正しい見方です。更新していないサイトは、日を追うごとに狙われやすくなります。
影響を受けるバージョンと修正版の一覧
影響を受けるのはWordPress 4.7.0から7.1.1までのすべてのバージョンです。修正版は最新の7.1.2に加えて、古い系列にも「その系列のまま使える修正版」が用意されています。
9月17日に出た7.1.1も対象
注意したいのは、9月17日に公開されたばかりの7.1.1も対象に含まれる点です。7.1.1は11件のセキュリティ修正を含む更新だったため、「先週更新したから大丈夫」と考えている方が多いはずです。しかし今回の脆弱性はその後に見つかったもので、7.1.1では修正されていません。管理画面のバージョン表示が「7.1.1」なら、もう一度更新が必要です。
系列ごとの修正版バージョン
自分のサイトのバージョンが下の表の「修正版」以上になっていれば対処済みです。それより古い番号なら未対処です。
| 使っている系列 | 修正版 | 使っている系列 | 修正版 |
|---|---|---|---|
| 7.1.x | 7.1.2 | 6.0.x | 6.0.16 |
| 7.0.x | 7.0.6 | 5.9.x | 5.9.18 |
| 6.9.x | 6.9.9 | 5.8.x | 5.8.17 |
| 6.8.x | 6.8.10 | 5.7.x | 5.7.19 |
| 6.7.x | 6.7.9 | 5.6.x | 5.6.21 |
| 6.6.x | 6.6.9 | 5.5.x | 5.5.22 |
| 6.5.x | 6.5.12 | 5.4.x | 5.4.23 |
| 6.4.x | 6.4.12 | 5.3.x | 5.3.25 |
| 6.3.x | 6.3.12 | 5.2.x | 5.2.28 |
| 6.2.x | 6.2.13 | 5.1.x | 5.1.26 |
| 6.1.x | 6.1.14 | 5.0.x / 4.9.x / 4.8.x / 4.7.x | 5.0.29 / 4.9.33 / 4.8.32 / 4.7.37 |
出典はWordPress公式のVersion 7.1.2ドキュメントです。エックスサーバーの案内にある「9月22日以降にリリースされた各バージョン毎の最新版」とは、この表の修正版のことを指しています。
4.6以前は修正版が出ない
WordPress 4.6以前はセキュリティ更新の提供対象から外れており、今回の修正版もありません。この世代のサイトが残っている場合は、部分的な更新ではなく最新版への移行を前提に計画を立てる必要があります。テーマやプラグインの互換性を確認したうえで、テスト環境で更新を試してから本番に反映する流れが安全です。
攻撃が成立する条件｜「うちは大丈夫」と決めつけない
エックスサーバーの案内にある「特定のテーマ利用や、一部設定を変更されている場合に攻撃の対象となる」という表現は、この脆弱性が「乗っ取りまで到達する」には複数の条件が重なる必要があることを指しています。ただし条件は一般的な環境で満たされうるもので、自分で確認しきれないなら「対象である」前提で動くべきです。
条件1｜テーマに「page-」で始まるフォルダがある
有効化しているテーマ（親テーマまたは子テーマ）の直下に、名前が「page-」で始まるディレクトリがある場合に、テンプレート解決の処理が悪用される入口になります。典型例は固定ページ用のテンプレートをまとめて置く「page-templates」フォルダで、市販テーマや制作会社のオリジナルテーマでよく使われる構成です。テーマフォルダ直下にある「page-contact.php」のようなファイルではなく、フォルダが条件になります。
条件2｜PHPの設定 register_argc_argv が有効
ファイルを読み込ませるだけでなく命令を実行させるには、PHPの設定 register_argc_argv が有効になっている必要があります。この設定が有効だと、URLのクエリ文字列がコマンドライン引数のように扱われるため、読み込んだPHPファイルに攻撃者の指示を渡せます。公式のPHP Dockerイメージや、PHP 8.5未満のcPanel環境では既定で有効になっていると報告されています。レンタルサーバーでは事業者ごとに設定が異なるため、サーバーのPHP設定画面や phpinfo で確認します。
条件3｜サーバー上に「使えるPHPファイル」がある
攻撃者が読み込ませるのはWordPressのファイルとは限りません。実際の攻撃では、PHPに同梱されるPEARの管理ツール「pearcmd.php」が狙われています。このファイルは引数次第で任意の場所にファイルを書き出せるため、これを経由して /tmp などにPHPの実行ファイルを作る手口が観測されています。
条件がそろわなくても更新が必須な理由
3つの条件が現時点でそろっていなくても、更新を後回しにする理由にはなりません。理由は3つあります。1つ目は、テーマの入れ替えやサーバーの仕様変更で条件が後からそろうこと。2つ目は、pearcmd.php以外の「使えるファイル」を探す新しい手口が今後出てくる可能性が高いこと（エックスサーバーの案内も「今後新たな攻撃手法が公開された場合に影響を受ける可能性」に言及しています）。3つ目は、そもそも本体の不具合なので修正版を当てる以外に根本的な解決がないことです。
自分のサイトが対象か確認する手順
確認は「バージョン」「更新の完了」「テーマの構成」「サイトの棚卸し」の4段階で行います。所要時間は1サイトあたり5分程度です。
ステップ1｜管理画面でバージョンを確認する
WordPressにログインし、「ダッシュボード」→「更新」を開きます。画面上部に「最新バージョンのWordPressをお使いです」と表示され、その下のバージョン番号が前述の表の修正版以上であれば対処済みです。ダッシュボードのトップにある「概要」ウィジェットにもバージョンが表示されます。
ステップ2｜自動更新が「完了しているか」を確認する
WordPressは既定で、同じ系列内のマイナー更新（7.1.1から7.1.2など）を自動で適用します。ただし自動更新は必ず成功するとは限りません。ファイルの書き込み権限が足りない、wp-config.php で自動更新を止めている、Gitなどのバージョン管理下にある、といった理由で止まっているサイトは珍しくありません。エックスサーバーが「自動更新を有効にされている場合も、実際にアップデートが完了しているか管理画面にてご確認ください」と念を押しているのはこのためです。更新画面で「7.1.2に更新してください」のような表示が残っていれば、自動更新は動いていません。
ステップ3｜有効化中のテーマのフォルダ構成を確認する
「外観」→「テーマ」で有効化しているテーマ名を確認し、FTPやサーバーのファイルマネージャーで wp-content/themes/テーマ名/ を開きます。直下に「page-」で始まるフォルダがあれば条件1に該当します。子テーマを使っている場合は親テーマと子テーマの両方を確認してください。該当しても更新は必要ですが、該当するなら優先度をさらに上げて当日中に対応します。
ステップ4｜複数サイト・放置サイトを洗い出す
制作の現場でいちばん漏れやすいのは、メインサイトではなく「テスト用に作ったサブドメインのWordPress」「キャンペーンで使い終わったLP」「担当者が変わって誰も見ていない旧サイト」です。同じサーバー内にあるWordPressは、どれか1つが乗っ取られると横のサイトにも被害が広がります。サーバーパネルのドメイン一覧やWordPress簡単インストールの履歴から、稼働中のWordPressをすべて書き出してください。
更新手順｜環境別に解説
今回の修正は wp-includes/template.php の1ファイルだけで、テーマやプラグインの互換性に影響する変更は含まれていません。マイナー更新なので、通常は数分で完了します。
更新前にバックアップを取る
マイナー更新とはいえ、更新の途中でサーバーとの通信が切れると画面が真っ白になることがあります。事前にファイルとデータベースのバックアップを取ってから作業してください。エックスサーバーなら、サーバーパネルの「自動バックアップ」からデータを取得できます。手順はWordPressバックアップ完全ガイドで解説しています。
管理画面から更新する（基本）
「ダッシュボード」→「更新」を開き、「今すぐ更新」をクリックします。更新中はメンテナンスモードになり、サイトが一時的に表示されなくなりますが、通常は1分以内に戻ります。完了後、同じ画面でバージョン番号が修正版になっていることと、サイトの表側が正常に表示されることを確認します。
WP-CLIで更新する（SSHが使える場合）
複数サイトをまとめて更新する場合や、管理画面のログイン情報が手元にない場合は、SSHで接続してWP-CLIを使うと早く確実です。WordPressのフォルダに移動してから、次のコマンドを実行します。
wp core version
wp core update
wp core version1行目で現在のバージョン、2行目で更新、3行目で更新後のバージョンを確認します。古い系列のまま最新版に上げたくない場合は、「wp core update –version=6.9.9」のように系列内の修正版を指定します。
古い系列を使っている場合の考え方
6.x系などの古い系列を使っているサイトは、「まず同じ系列の修正版に上げて穴をふさぐ」→「落ち着いてから最新版への移行を計画する」の2段構えが現実的です。WordPress公式は「積極的にサポートされるのは最新版のみ」と明言しており、古い系列への修正版提供はあくまで「好意による提供」です。次回以降も提供される保証はないため、最新版へ追いつく計画は別途必要です。
エックスサーバー利用者が合わせて見ておく設定
今回の脆弱性はWordPress本体の更新でしか根本的に解決しませんが、エックスサーバーのサーバーパネルには多層防御に使える機能があります。「セキュリティ」→「WAF設定」で対象ドメインのWAFをONにしておくと、既知の攻撃パターンを含む通信をサーバー側で遮断できます。「WordPressセキュリティ設定」では国外IPからの管理画面アクセス制限やログイン試行回数の制限が設定できます。いずれも更新の代わりにはなりませんが、更新後の「二重の備え」として有効です。公式の案内はエックスサーバーのお知らせ（2026年9月24日）とWAF設定マニュアルをご覧ください。
すぐに更新できないときの応急対処
「テーマの改修中で今は触れない」「更新の承認に時間がかかる」といった事情で当日中に更新できない場合は、次の応急対処で攻撃の成立条件を崩します。ただし、いずれも時間稼ぎであって、更新の代わりにはなりません。
対処1｜pagename パラメータの「..」を遮断する
攻撃は pagename に上位ディレクトリへ移動する文字列（「..」やそれをURLエンコードした「%2e%2e」「%252e%252e」）を含めて送られます。WAFや .htaccess でこの文字列を含むリクエストを拒否すると、既知の手口を止められます。エックスサーバーのWAFをONにしていれば、この種の攻撃パターンは遮断対象に含まれる可能性が高いですが、遮断ルールの詳細は公開されていないため過信は禁物です。
対処2｜register_argc_argv を無効化する
PHPの設定で register_argc_argv を Off にすると、ファイルを読み込まれても命令の実行までは到達しにくくなります。エックスサーバーではサーバーパネルの「php.ini設定」から変更できます。ただし、この設定に依存しているプラグインやバッチ処理があると動かなくなるため、変更後は主要な機能を一通り確認してください。
対処3｜使っていないPEARの実行ファイルを封じる
自分でサーバーを管理している場合は、pearcmd.php をはじめ使っていないPEARの管理ファイルを削除するか、Webサーバーの実行ユーザーから読めない権限にしておきます。共用レンタルサーバーでは利用者側で変更できないことが多いので、その場合は対処1と対処2、そして本体の更新で対応します。
応急処置は「時間稼ぎ」でしかない
7月のwp2shellのときも、サーバー事業者側の遮断対応で一時的に攻撃は止まりましたが、遮断の対象は「その時点で知られている手口」に限られます。詳しくはwp2shellはサーバー側の遮断だけでは防げないで書いたとおりです。今回も同じで、pagename の検査を通り抜ける新しい書き方が見つかれば、応急処置はすり抜けられます。応急処置を入れたら、その日のうちに更新の予定を確定させてください。
すでに攻撃されていないか確認する｜痕跡の見つけ方
更新が9月22日より後になったサイトは、その間に攻撃を受けていないかを確認しておくと安心です。見るべき場所はアクセスログとサーバー上のファイルの2つです。
アクセスログで探す文字列
エックスサーバーではサーバーパネルの「アクセスログ」からドメインごとのログをダウンロードできます。9月22日以降のログを開き、次の文字列を検索します。
| 探す文字列 | 意味 |
|---|---|
| pagename= に続く %2e%2e や %252e%252e | 上位ディレクトリへ移動する文字列。攻撃の入口 |
| サイトのトップに pagename と page_id が同時に付いたリクエスト | テンプレート解決を狙う典型的な組み合わせ |
| pagename=templates%2f のように「page-」フォルダ名で始まる値 | 条件1の「page-」フォルダを踏み台にする試行 |
| pearcmd、+config-show、+config-create | PEAR経由でファイルを書き込む段階の試行 |
| wp-links-opml.php への不自然なアクセス | 脆弱性の有無を確かめる偵察段階 |
これらが見つかっても、即「侵害された」とは限りません。スキャンツールによる総当たりは、条件がそろわないサイトにも無差別に届くためです。ただし「+config-create」を含むリクエストに対してサーバーが200番台の応答を返している場合は、ファイル書き込みが成功した可能性を疑います。
見覚えのないPHPファイルがないか
観測されている攻撃では、/tmp や /var/tmp に「wp-pear-rce-flag.php」「poc87902.php」といった名前のPHPファイルを作る手口が確認されています。名前は攻撃者ごとに変わるため、名前ではなく「9月22日以降に作られた、自分で作った覚えのないPHPファイル」を基準に探します。WordPressのフォルダ内では、wp-content/uploads 配下にPHPファイルがあれば、それ自体が異常です。
痕跡が見つかったときの初動
不審なファイルや成功した形跡が見つかった場合は、まず本体を更新して穴をふさぎ、次に管理者と全ユーザーのパスワード、データベースのパスワード、FTP・SSHの認証情報を変更します。そのうえで、改ざんの範囲を特定するために、更新前のバックアップと現在のファイルを比較します。自力での切り分けが難しい場合は、ログとバックアップを消さずに保全したまま専門業者や制作会社に相談してください。ログを消してしまうと、被害範囲の特定ができなくなります。
制作会社の視点｜更新が止まっているサイトが一番危ない
今回の脆弱性そのものは、修正版を当てれば数分で解決します。本当の問題は「更新が止まっているサイトがどれだけあるか」です。WordPress本体では、7月のwp2shell（CVE-2026-60137／63030）に続き、9月17日の7.1.1（11件のセキュリティ修正）、9月22日の7.1.2と、2か月余りで重大な修正が立て続けに出ています。この頻度は今後も下がらないと考えたほうがよく、「気づいたときに更新する」運用では追いつきません。
お客様のサイトで実際によくあるのは、「自動更新が有効だと思っていたが、テーマの改修時に止めたまま戻していなかった」「制作会社との保守契約が終わって以降、誰も管理画面を開いていない」という状態です。サイト制作の観点では、公開後の運用に「月1回のバージョン確認」と「重大な脆弱性が出たときの臨時対応」を最初から組み込んでおくことが、結果的にいちばん安上がりです。乗っ取られたサイトの復旧は、通常の保守費用の数か月分から数年分に相当します。
本体の更新とあわせて、ログインまわりの対策と定期バックアップを整えておくと、次に同じような脆弱性が出たときも慌てずに対応できます。
よくある質問（FAQ）
Q. 9月17日に7.1.1へ更新したばかりですが、また更新が必要ですか？
A. 必要です。7.1.1は今回の脆弱性の対象に含まれています。修正されたのは9月22日公開の7.1.2からです。
Q. 自動更新を有効にしていれば何もしなくてよいですか？
A. 管理画面で「実際に修正版になっているか」の確認は必要です。自動更新は書き込み権限不足や設定で止まっていることがあり、有効にしているつもりでも適用されていないケースがあります。
Q. エックスサーバー以外のサーバーを使っていても対象ですか？
A. 対象です。これはWordPress本体の脆弱性なので、サーバー事業者に関係なく該当バージョンのWordPressすべてが影響を受けます。エックスサーバーの案内は自社利用者向けの注意喚起であって、対象範囲を限定するものではありません。
Q. テーマに「page-」フォルダがなければ更新しなくてよいですか？
A. 更新は必要です。「page-」フォルダは現時点で知られている攻撃の成立条件の1つにすぎず、今後別の手口が見つかる可能性があります。本体の不具合は本体の更新でしか解決しません。
Q. 更新するとテーマやプラグインが壊れませんか？
A. 今回の7.1.2は wp-includes/template.php の1ファイルを修正しただけのマイナー更新で、機能の追加や仕様変更はありません。通常はテーマやプラグインへの影響はありませんが、念のため更新前にバックアップを取り、更新後に表示を確認してください。
Q. 古いWordPressを使っていて最新版に上げるのが怖いです。どうすればよいですか？
A. まず同じ系列の修正版（6.8.xなら6.8.10など）に上げて今回の穴をふさぎ、その後に最新版への移行をテスト環境で検証する2段構えをおすすめします。4.6以前は修正版がないため、最新版への移行を前提に計画してください。
THREE D PLUS は大阪の Web 制作会社です。WordPressサイトのバージョン確認・更新代行から、公開後の保守・運用、万一のときの復旧までまとめてご相談いただけます。お問い合わせはこちら。
