WordPressの脆弱性「CVE-2026-87902」を狙い、PHPファイルの書き込みやコード実行につなげようとする攻撃が観測されています。WordPressは2026年9月22日に修正版7.1.2を公開し、速やかな更新を推奨しています*1。サイト運用者は修正版を適用するとともに、更新前に不正アクセスを受けていなかったか確認することが重要です。
CVE-2026-87902とは何か
CVE-2026-87902は、ページテンプレートの解決処理に存在するパストラバーサルの脆弱性です。認証されていない攻撃者が、利用中のテーマのディレクトリ外にある、読み取り可能なローカルPHPファイルを処理に取り込ませることができます。テーマとサーバー側の条件が重なると、リモートコード実行（RCE）につながる可能性があります。
影響条件には、有効な親テーマまたは子テーマの直下にpage-で始まるディレクトリがあることと、Webサーバーの実行アカウントから読み取り可能な対象PHPファイルが存在することなどが含まれます。公式情報では、PEARに含まれるpearcmd.phpと、PHP設定のregister_argc_argvがOnになっている環境を、RCEに至る経路の一つとして挙げています。[2] したがって、WordPressを使用しているという理由だけで、すべてのサイトで同じようにコード実行が成立するわけではありません。一方で、テーマやPHP環境を確認できていない段階で、自社サイトを影響対象外と判断することも避ける必要があります。
図1：CVE-2026-87902の成立条件と影響
※ローカルPHPファイルの読み込みからRCEに至るには追加の条件があり、pearcmd.php経由の例ではregister_argc_argv = Onであることが条件となります。
7.1.1への更新だけでは今回の対策にならない
CVE-2026-87902は、WordPress 7.1系列だけの問題ではありません。公式アドバイザリでは、7.1系列の影響範囲を7.1.0～7.1.1、修正版を7.1.2としています。また、旧系列にも修正版が提供されており、例えば7.0系列は7.0.6、6.9系列は6.9.9で修正されています。利用中のWordPressの系列と、公式アドバイザリに掲載されている修正版の一覧を照合する必要があります*2。更新作業を外部の制作会社や保守会社に任せている場合は、「対応しました」という連絡だけでなく、適用後のバージョンと実施日時も共有してもらうと管理しやすくなります。自動更新を利用しているサイトでも、処理が完了しているかを実際に確認しておきましょう。WordPress公式は、管理画面の更新機能に加え、対応している環境では自動バックグラウンド更新が開始されると案内しています。
観測された攻撃と侵害成功を区別して読む
Patchstackは2026年9月23日の更新で、単なる脆弱性の探索に加えて、pearcmd.phpを介して攻撃者が用意したPHPの内容をファイルへ書き込もうとするリクエストを報告しています*3。観測されたペイロードには、動作確認用の文字列を残すもののほか、アクセス時にシェルコマンドを実行させるものも含まれていました。これは、CVE-2026-87902を狙った実際の悪用活動が行われていることを示す報告です。一方で、Patchstackが観測したリクエストが、そのまますべての対象サイトで侵害に成功したことを意味するわけではありません。自社サイトについては、攻撃リクエストが到達していたか、ファイルが作成されていないか、コードが実行されていないかをそれぞれ確認する必要があります。
調査の手掛かりとして、Patchstackはpagenameに不審なトラバーサル表現を含むリクエストや、pearcmd、config-show、config-createに関係する痕跡、/tmpや/var/tmpに作成された不審なPHPファイルなどを挙げています。これらは、担当者がログやファイルを確認する際の手掛かりです。該当する語句やファイルが存在することだけで侵害を断定することはできません。また、ログの保存期間や取得対象によっては記録そのものが残っていない場合もあるため、該当する痕跡が見つからないことだけで侵害を否定することもできません。
更新と並行して確認したいサイトの状態
サイトに不審な変化が確認された場合は、発見時刻、表示内容、直前に行った運用変更などを記録し、ホスティング事業者や保守会社に連絡します。WordPress公式の侵害対応ガイドでも、状況を記録することやホスティング事業者に確認すること、クリーンアップ前に環境のスナップショットを保存することなどが案内されています*4。原因を調べる前に不審なファイルを一括して削除すると、侵入経路や影響範囲を確認するための情報を失う可能性があります。そのため、不正アクセスが疑われる場合は、修正や削除を進めるだけでなく、必要な記録やデータを保存することも検討します。
実務では、更新を行う担当者と、侵害の有無を確認する担当者を明確にしておくことも重要です。更新によって脆弱な処理を修正できても、すでに追加された不審なファイルや不正なアカウントの有無は別途確認する必要があります。調査によって侵害が判明した場合は、影響範囲を把握したうえで封じ込めを進め、復旧後の認証情報の変更や再発防止策も含めて対応を検討します。
図2：更新と侵害確認を並行して進める対応例
※封じ込め・証拠保全・更新の具体的な順序は、被害状況に応じて判断します。
日常のWordPress運用に残したい対策
今回の対応を終えた後は、誰がどのサイトを管理しているか、更新情報を誰が受け取るかまで見直しておきましょう。例えば、コーポレートサイトとは別に運用している採用サイトやキャンペーンサイトについても、同じ管理台帳で確認できるようにしておくと、脆弱性が公表された際に対象サイトを探すところから始めずに済みます。WordPress公式のセキュリティ強化ガイドでは、WordPress本体やサーバ側ソフトウェアを最新の状態に保つこと、アクセスを適切に制限すること、データベースやファイルをバックアップすることなどが案内されています*5。実務では、バックアップを取得しているかだけでなく、復元に必要なデータがそろっているか、復旧を依頼する連絡先が明確になっているかまで確認しておくことが重要です。
侵害が疑われる場合はBBSecの緊急対応支援へ
不審なPHPファイルが見つかった、サイトが改ざんされた、更新前に侵害されていなかったか自社だけでは判断できない、といった場合には、BBSecのデジタルフォレンジックを含む緊急対応支援をご相談いただけます。デジタルフォレンジックは、サーバや端末などに残されたデータを調査し、何が起きたのかを明らかにするための調査です。BBSecでは、インシデント発生時の事象把握、証拠保全・データ収集、原因調査、再発防止に向けた事後対策方針の検討などを支援しています。
緊急コンタクトセンターでは、取引の有無にかかわらず24時間365日相談を受け付けています。相談時には、対象サイト、利用しているWordPressのバージョン、異常を発見した時刻、すでに実施した作業などを整理しておくと、状況を伝えやすくなります。
平時の対策や復旧後の見直しには、Webアプリケーション・API脆弱性診断「SQAT® for Web」を活用できます。自動ツールによる診断とエンジニアによる手動診断を組み合わせ、攻撃の入口となる可能性のある問題箇所を確認するサービスです。脆弱性診断と、過去の侵害状況を調べるデジタルフォレンジックでは目的が異なります。すでに侵害が疑われている場合は、まず現在の状況や懸念点を伝えたうえで、ブロードバンドセキュリティ（BBSec）までご相談ください。
【参考情報】
- WordPress 7.1.2 Release（2026年9月22日公開）（https://wordpress.org/news/2026/09/wordpress-7-1-2-release/）
- WordPress「GHSA-7hp8-65ch-5whp」（https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-7hp8-65ch-5whp）
- Patchstack「CVE-2026-87902: Attackers Started Probing WordPress Sites Hours After the Patch」（https://patchstack.com/articles/cve-2026-87902-attackers-started-probing-wordpress-sites-hours-after-the-patch/）
- WordPress「FAQ My site was hacked」（https://wordpress.org/documentation/article/faq-my-site-was-hacked/）
- WordPress「Hardening WordPress」（https://developer.wordpress.org/advanced-administration/security/hardening/）
編集責任：木下
ウェビナー開催のお知らせ
最新情報はこちら
