WordPress重大な脆弱性 CVE-2026-87902のサイバー攻撃 悪用を確認-71.2など修正版へ更新を

セキュリティニュース

投稿日時: 更新日時:

WordPress重大な脆弱性 CVE-2026-87902のサイバー攻撃 悪用を確認-71.2など修正版へ更新を

WordPress Coreの重大な脆弱性「CVE-2026-87902」を狙った攻撃が、修正版の公開当日から観測されています。WordPress公式アドバイザリはCVSS v4.0で9.2(Critical)と評価しており、認証されていない攻撃者がページテンプレートの解決処理を悪用し、特定条件下でローカルPHPファイルを読み込ませ、リモートコード実行(RCE)につなげられる可能性があります。

WordPressは2026年9月22日に7.1.2を公開し、旧ブランチにも4.7まで修正をバックポートしました。Patchstackは同日11:49 UTCに最初の悪用試行を観測し、15:34 UTCには脆弱性を利用したファイル書き込み試行を確認しています。翌23日には攻撃トラフィックが初日の10倍超に増え、公開スキャンツールも確認されました。

CVE-2026-87902のサマリー

  • CVE-2026-87902はWordPress Coreのページテンプレート解決処理に存在するパストラバーサル/ローカルPHPファイルインクルードの脆弱性です。
  • WordPress公式はCVSS v4.0で9.2、Criticalと評価しています。
  • 攻撃にWordPressアカウントや管理者権限は不要です。
  • 特定のテーマ構成とサーバー環境がそろった場合、RCEにつながる可能性があります。
  • WordPress 7.1.0~7.1.1を含む複数の旧ブランチが影響を受け、修正版は7.1.2、7.0.6、6.9.9など、4.7.37まで提供されています。
  • Patchstackは2026年9月22日11:49 UTCに最初の悪用試行を観測しました。
  • 同日15:34 UTCには、脆弱性を利用してPHPファイルをディスクへ書き込もうとする試行が確認されています。
  • 9月23日には関連トラフィックが初日の10倍超に増加し、コード実行につながる攻撃も観測されています。
  • 脆弱性の発見者Robert Ressl氏は9月22日にPoCを公開しています。
  • 2026年9月24日時点で、CISA Known Exploited Vulnerabilities(KEV)カタログへの掲載は確認できませんでした。
  • 修正前にインターネット公開していたサイトでは、更新だけでなくWebアクセスログとサーバー上の不審ファイルも確認対象になります。
項目 内容
CVE CVE-2026-87902
対象 WordPress Core
深刻度 Critical
CVSS 9.2(CVSS v4.0、WordPress公式)
CWE CWE-98
認証 不要
主な影響 ローカルPHPファイルの読み込み、条件成立時のRCE
影響範囲 WordPress 4.7.0~7.1.1の各対象ブランチ
最新ブランチの修正版 WordPress 7.1.2
旧ブランチの修正版 7.0.6、6.9.9、6.8.10など、4.7.37まで
PoC 公開済み
実悪用 Patchstackが確認
最初の悪用試行 2026年9月22日 11:49 UTC
最初のファイル書き込み試行 2026年9月22日 15:34 UTC
CISA KEV 2026年9月24日時点で掲載を確認できず

未認証のページテンプレート処理からローカルPHPファイルを読み込める脆弱性

WordPress公式アドバイザリによると、CVE-2026-87902はget_page_template()によるページテンプレート解決処理に存在します。

認証されていない攻撃者が、アクティブテーマのディレクトリ外にある読み取り可能なローカルPHPファイルをテンプレートとして読み込ませることができます。これは単なる情報漏洩にとどまらず、サーバー環境とテーマ構成が特定条件を満たす場合、PHPコードの実行につながります。

WordPress公式は、RCEへ到達する条件として、アクティブな親テーマまたは子テーマにpage-で始まるトップレベルディレクトリが存在すること、サーバー上にWebサーバーアカウントから読み取り可能なPHPファイルが存在することなどを挙げています。

発見者のRobert Ressl氏も、すべてのWordPressサイトがそのままRCE可能になるわけではないと説明しています。同氏が検証した攻撃経路では、テーマ構成、PHP実行環境、ローカルファイル、書き込み権限など複数の条件が必要でした。

したがって「WordPress 7.1.1以前なら必ずRCEされる」とするのは正確ではありません。一方、WordPressアカウントなしで攻撃可能であり、条件がそろった環境では機密性・完全性・可用性への影響が大きいため、WordPress公式はCriticalと評価しています。

WordPress 7.1.2公開当日から悪用試行を観測

WordPressは9月22日、CVE-2026-87902を修正したWordPress 7.1.2を公開しました。

同日、Patchstackは自社ファイアウォールでCVE-2026-87902を狙ったトラフィックを観測しています。Patchstackが現在公表しているタイムラインでは、最初の悪用試行は11:49 UTCでした。

初期の攻撃は、対象サイトが脆弱かどうかを確認するスキャンが中心でした。攻撃者はWordPress Coreに存在する無害なファイルを読み込ませ、脆弱なコード経路が動作するかを確認していたとされています。

状況は同日中に変化しました。Patchstackは15:34 UTCに、脆弱性を利用してサーバー上へファイルを書き込もうとする最初の試行を確認しています。

9月23日には関連トラフィックが初日の10倍を超え、単なる脆弱性調査ではなく、攻撃者が制御するPHPコンテンツをディスクへ書き込む段階へ進みました。Patchstackは、一部のペイロードについて、ファイルがアクセスされた際にシェルコマンドを実行する内容だったと報告しています。

公開スキャンツールも確認、攻撃の裾野が拡大

Patchstackは9月23日、CVE-2026-87902を対象とした公開スキャンツールが流通していることも確認しました。

同社の観測では、初日は少数の送信元から始まったトラフィックが、その後数百の送信元へ拡大しています。このため、特定IPアドレスだけをブロックする対策では継続的な防御にならないとしています。

発見者のRessl氏も9月22日にPoCと検証用ラボを公開しています。PoC公開とパッチ差分の解析が重なり、修正版公開から短時間で攻撃者が脆弱性の仕組みを把握できる状況になりました。

今回のケースでは、「修正版が公開された後に余裕を持って更新する」という運用では、攻撃開始に間に合わない可能性があります。インターネット公開しているWordPressについては、CriticalのCore脆弱性が公開された場合の緊急更新手順をあらかじめ決めておく必要があります。

影響バージョンと修正版

WordPress公式アドバイザリでは、4.7以降の複数ブランチが影響対象として掲載されています。

主な修正版は次のとおりです。

ブランチ 修正版
7.1 7.1.2
7.0 7.0.6
6.9 6.9.9
6.8 6.8.10
6.7 6.7.9
6.6 6.6.9
6.5 6.5.12
6.4 6.4.12
6.3 6.3.12
6.2 6.2.13
6.1 6.1.14
6.0 6.0.16
5.9 5.9.18
5.8 5.8.17
5.7 5.7.19
5.6 5.6.21
5.5 5.5.22
5.4 5.4.23
5.3 5.3.25
5.2 5.2.28
5.1 5.1.26
5.0 5.0.29
4.9 4.9.33
4.8 4.8.32
4.7 4.7.37

WordPress.orgは、最新バージョンだけが積極的にサポートされると説明しています。旧ブランチ向けのバックポートは今回の脆弱性に対する例外的な対応です。

4.6以前については今回の修正版は提供されません。古いWordPressを継続利用している場合は、今回の個別パッチだけでなく、サポート対象バージョンへの更新計画そのものを見直す必要があります。

CISA KEV掲載は9月24日時点で確認できず

CVE-2026-87902は実際の悪用がPatchstackによって確認されていますが、2026年9月24日時点でCISAのKnown Exploited Vulnerabilities(KEV)カタログへの掲載は確認できませんでした。

「実悪用が確認された脆弱性」と「CISA KEVに掲載された脆弱性」は同義ではありません。

企業側ではKEV掲載を待って対応を開始するのではなく、WordPress公式のCritical評価、認証不要という条件、Patchstackが確認した攻撃状況をもとに優先度を判断する必要があります。

修正版適用前に公開していたサイトはログ確認も必要

すでに攻撃が始まっているため、WordPressを更新するだけでは、修正前に侵害されていなかったことまでは確認できません。

Patchstackは、Webアクセスログについて、pagenamepage_idが同時に使われた不審なリクエスト、パストラバーサルを示すエンコード文字列、PEAR関連の参照などを調査するよう案内しています。

サーバー側では、一時ディレクトリなどに予期しないPHPファイルが作成されていないかも確認対象です。不審なファイル書き込みが成功していた場合は、単なるスキャンではなく侵害として扱い、認証情報の変更、WebサーバーとWordPressのログ保全、ファイル改ざん確認、外部通信の調査まで範囲を広げます。

攻撃リクエストの具体的な再現手順や実行可能なペイロードは、管理者向けの確認に必要ないため本稿では掲載しません。

情報システム部門が確認したいポイント

WordPressを社内で直接管理していない場合でも、コーポレートサイト、採用サイト、オウンドメディア、キャンペーンサイトなどで外部委託先がWordPressを利用しているケースがあります。

確認対象は次のとおりです。

  • 管理対象および委託先管理のWordPressサイトを一覧化する
  • WordPress Coreの現在バージョンと修正版適用状況を確認する
  • 7.1系では7.1.2、旧ブランチではWordPress公式アドバイザリに記載された修正版以上か確認する
  • 自動更新が有効でも、実際に更新が完了したか管理画面やバージョン情報で確認する
  • 9月22日以降のWebアクセスログを保存し、不審なテンプレート探索やファイルインクルードの痕跡を調べる
  • /tmpなどの一時領域を含め、不審なPHPファイルが作成されていないか確認する
  • 不審なファイル書き込みが確認された場合は、サイト更新だけで終了せずインシデント調査へ切り替える
  • WordPress本体の緊急パッチを、通常の変更管理より優先して適用できる手順を整備する
  • 制作会社や運用委託先との契約で、Critical脆弱性発生時の通知・更新期限・ログ提供範囲を確認する

関連記事:

出典