WordPressのパストラバーサル脆弱性CVE-2026-87902の悪用

脆弱性の内容

WordPressのセキュリティアドバイザリ（GHSA-7hp8-65ch-5whp）によると、脆弱性はget_page_template()によるページテンプレートの解決処理にある⁠［2］。認証されていない攻撃者は、有効なテーマのディレクトリの外にある読み取り可能なローカルの.phpファイルを選んで、この処理に読み込ませられる⁠［2］。前提条件の一つは、有効な子テーマか親テーマの最上位に、page-で始まる名前のディレクトリ（page-templatesなど）があることだ⁠［2］。もう一つの条件として、選んだローカルの.phpファイルがサーバー上にあり、Webサーバーのアカウントで読めなければならない⁠［2］。

WordPressは、テーマの条件に当たるものとして、旧来のTwenty TwelveとTwenty Fourteen、Neve・Hestia・Sydneyなど一部の人気のあるサードパーティ製テーマを挙げた⁠［2］。register_argc_argvがOnの環境では、よく知られたpearcmd.phpの手法で、PEARからリモートでのコード実行（RCE）へ移れる⁠［2］。Docker公式のphpイメージは影響を受け、cPanelも既定の構成でPHP 8.5より前の版を動かしていれば影響を受けるとした⁠［2］。

WordPress Core Tracの9月22日の修正コミット（Changeset 63792）では、デコードした後のpagenameにvalidate_file()を通す処理を加えた⁠［4］。locate_template()が見つけたテンプレートを読み込んでよいかを判定する非公開の関数_wp_is_template_path_allowed()も、7.1.2で新しく設けた⁠［4］。この関数は、..を含むパスを実際のパス（realpath）に直し、stylesheet・template・theme-compatのディレクトリの中に収まるかを確かめる⁠［4］。

発見者はブログで、WordPress 7.0.2を隔離したローカルの環境に置いて悪用を検証したと書いた⁠［19］。調べたTwenty Twenty-Three・Twenty Twenty-Four・Twenty Twenty-Fiveには、最上位のpage-*ディレクトリが無かった⁠［19］。検証環境では、Twenty Twenty-Fiveに空のディレクトリを意図的に加えた⁠［19］。得られた権限は、PHPとWebサーバーが動くアカウントの権限（検証環境ではwww-data）だった⁠［19］。

発見者の9月22日のブログでは、インクルードの条件に、page_idで選べる匿名で閲覧できる公開ページがあること、先に割り当てた有効なカスタムテンプレートが無いこと、ファイルシステムのポリシーがインクルードを許すことも挙げた⁠［19］。OSでの権限の昇格やroot権限の取得は示していない⁠［19］。PEARはWordPressが依存するものではなく、この経路はすべての環境で使えるわけではないとした⁠［19］。条件を満たすサイトの数は測っておらず、第三者や本番のサイトでは試していないと説明した⁠［19］。

目次へ

時系列

目次へ

対象の製品と版

WordPressは7.1.2のリリースノートで、4.6以前の版はセキュリティ更新を受けないとした⁠［3］。Security NEXTは、9月17日に公開された7.1.1で修正した脆弱性とは別の問題で、再度の更新が必要になると報じた⁠［25］。

Wordfenceの9月22日の注意喚起では、修正していないすべてのWordPressのサイトで、無条件にRCEが成り立つわけではないと説明した⁠［21］。アドバイザリにテーマの影響を受ける版の範囲が書かれていないとして、名前だけで露出を判断せず、導入したテーマとファイルシステムを確かめるよう求めた⁠［21］。

目次へ

悪用の状況

Patchstackの報告によると、最初の試行は9月22日11時49分（UTC）にファイアウォールに届いた〔注2〕⁠［20］。ペイロードはパッチが対処したエンコードと一致し、作った者は修正の差分をもとにしていたと説明した⁠［20］。15時34分（UTC）には、pearcmdを通じてディスクにファイルを書き込む最初の試行があった⁠［20］。

Patchstackの9月23日の更新では、攻撃はpearcmd.phpを読み込んでPHPファイルをディスクに書き込む段階に進み、この脆弱性を狙う公開のスキャンツールが出回っていると報告した⁠［20］。通信量は初日の夕方の10倍を超え、リクエストは脆弱性の確認、pearcmdに届くかの確認、config-createでのファイルの書き込みの3段階を経ていた⁠［20］。件数は同じ日の正午（UTC）ごろに最も多くなり、POSTがGETを上回った⁠［20］。送信元は初日の少数から数百に広がり、個々の送信元をブロックリストに載せても対策にならないとした⁠［20］。

Patchstackは、/tmpに置いたファイルは通常Webから届かないため、それだけでは残り続けるバックドアではなく実行の証明だと説明した⁠［20］。攻撃者の側から見れば、ホストは完全に侵害された状態になるとも書いた⁠［20］。表の2つのUser-Agent以外の通信の大半は偽装したブラウザのUser-Agentを使っているとして、User-Agentを絞り込みの条件にしないよう求めた⁠［20］。トラバーサルの深さは1〜12段で、大文字の16進数や1重・2重のエンコードの変種もあり、1つの文字列に固定したルールやログの検索では見落とすとした⁠［20］。

CrowdSecの9月28日のレポートでは、この脆弱性のパターンに一致するシグナルを322,680件記録した⁠［22］。記録の期間は9月23日〜27日の5日間だった⁠［22］。1日の件数は14,938件から124,154件に増え、固有の送信元は237から23,321になった⁠［22］。Live Exploit Trackerでは、9月28日の集計で30,813のユニークなIPアドレスを数えた⁠［22］。

CrowdSecは、一致したリクエストは悪用の試行で、成功したかは確認できないと説明した⁠［22］。1つの運用者が数千のクラウドやプロキシのアドレスを使い回せるため、IPアドレスの数は攻撃者の数と一致しないとした⁠［22］。集計は、CrowdSec Networkに参加する機器に届いた通信の標本だとも書いた⁠［22］。

Previdianの10月24日更新のページによると、試行は9,253回で、送信元は37のIPアドレス、16か国にわたった⁠［23］。観測に使ったセンサーは5台だった⁠［23］。

オランダのNCSCは9月24日のアドバイザリの更新で、公開の情報源が悪用の観測を報告していると追記した⁠［18］。悪用には複数の前提条件が要り、個々の設定に強く左右されるとも書いた⁠［18］。

CISAの9月25日のKEVカタログへの登録では、対応の期限を9月28日とし、ランサムウェアの攻撃での使用を「Unknown」とした⁠［14］。

目次へ

修正と回避策

WordPressはリリース告知で、セキュリティリリースのため直ちにサイトを更新するよう推奨した⁠［1］。バックグラウンドでの自動更新が使えるサイトでは、更新の処理が自動的に開始される⁠［1］。修正はセキュリティ修正を受けられる全ブランチ（現在は4.7まで）にバックポートし、積極的にサポートしているのは最新版だけだとした⁠［1］。

発見者のブログによると、インクルードから実行までの経路を減らせる措置があるが、Coreの更新を補うもので、更新に置き換わるものではない⁠［19］。

• Webリクエストに使わないなら、register_argc_argvを切る⁠［19］。
• Webから読めるのに使っていないPEARの入口（エントリポイント）を消す⁠［19］。
• PHPのアカウントがファイルシステムにアクセスし書き込める範囲を絞る⁠［19］。

Patchstackは、すぐに更新できない場合の暫定策として、pagenameに含まれるトラバーサルの文字列を拒むことを挙げた⁠［20］。register_argc_argvを無効にしてもインクルードは直らないが、pearcmdを使う連鎖は断てると説明した⁠［20］。

Patchstackの記事の検知と緩和の節によると、/tmpと/var/tmpに想定外の.phpファイルが見つかれば、第3段階（ファイルの書き込み）の試行が通った証拠になる⁠［20］。そのホストは、スキャンを受けただけでなく侵害されたものとして扱うよう求めた⁠［20］。アクセスログで通常のページのURLからOPMLやRSSの出力が返っていれば、最初の段階のプローブが成功した兆候だとした⁠［20］。修正や緩和の前に露出していたサイトには、過去のログをその前提で見直すよう求めた⁠［20］。

Wordfenceは9月22日、Premium・Care・Responseの利用者に、この脆弱性への攻撃を防ぐファイアウォールのルールを提供した⁠［21］。無料版の利用者には、通常どおり30日遅れの10月22日に同じ保護を提供するとした⁠［21］。

Cloudflareの9月25日の緊急リリースでは、WAFのマネージドルールに、この脆弱性を狙う通信をブロックする新しい検知のルールを加えた⁠［24］。

ホスティング事業者の告知

エックスサーバーの9月24日の注意喚起によると、認証やログインは要らず、特定のテーマを使う場合や顧客が一部の設定を変えている場合に攻撃の対象になる⁠［5］。自社のサービスで、この脆弱性を悪用した被害は確認していないとした⁠［5］。

エックスサーバーは9月25日の追記で、悪用のリスクと緊急性を踏まえ、判明している攻撃の成立条件に当たるサイトのWordPress本体を、各系統の最新版へ更新したと告知した⁠［5］。更新は21時ごろ〜22時ごろに行った⁠［5］。サイトの状態によって更新を完了できなかったケースがあり、該当する顧客にはメールで知らせて自分で更新するよう求めた⁠［5］。エックスサーバーは公式のXアカウントで9月30日に、無料のセキュリティプラグイン「CloudSecure WP Security」に緩和策を加えたと告知した⁠［6］。

目次へ

未公表の事項

• 悪用に成功したサイトの数
• 影響を受ける版のまま公開されているサイトの数
• 攻撃者とその帰属
• WordPress.orgが自動更新を強制したかどうか
• エックスサーバー以外の国内のホスティング事業者のサービスでの被害の有無

注

• 〔注1〕CVEの記録でCISAが付けた評価と、JVN iPediaの評価は、CVSS 3.1の基本値8.1（攻撃条件の複雑さは高）だった⁠［15、17］。
• 〔注2〕Patchstackは記事の初版で、最初の試行を観測した時刻を9月22日17時44分（UTC）と書いていた⁠［20］。

出典

更新記録

• 2026年10月25日：公開した。
• 2026年10月26日2時13分：「悪用の状況」のCrowdSecとPrevidianの文と、「ホスティング事業者の告知」のエックスサーバーの更新の文を、それぞれ2つの文に分けた。
• 2026年11月2日：表1の発見者の行を、個人名から役割の表記に改めた。
• 2026年11月3日：「修正と回避策」と「脆弱性の内容」の文の言い回しを改めた（事実と出典は変えていない）。

目次へ

関連記事

この記事を参照する記事

• WordPressのテーマ自動インストールの脆弱性Click2Shell

  判明 2026年9月17日 公開 2026年9月29日 脆弱性の公表、国外