重大なWebセキュリティ脆弱性への対応をテーマにした、現実的で緊張感のあるエディトリアル・テクノロジーイラスト。中央に安全な状態へ更新されたWebサイトを象徴するサーバーと大きな青いシールド、周囲に赤い警告光と侵入を試みる抽象的なデータ経路。手前には管理者が確認するノートPCのターミナル画面とアクセスログの流れ、複数のログ行の一部が黄色や赤で強調され、パストラバーサルの試行痕跡を示す。ただし攻撃コードや具体的なペイロード、読める文字、URL、ロゴ、ブランド名は表示しない。背景にはデータセンターのサーバーラックと監視ダッシュボード、バックアップと更新を象徴するチェックマークや循環矢印を控えめに配置。攻撃そのものではなく、「まず更新し、その後ログを調査し、必要なら侵害対応する」という防御・監視のメッセージを表現。深いネイビー、黒、青を基調に、脅威を示す赤と警戒色のオレンジをアクセントにした、洗練された高品質のニュース記事用ビジュアル、リアルな照明、シネマティック、横長構図、文字なし。

WordPressの重大な脆弱性 CVE-2026-87902 — アクセスログで攻撃痕跡を確認する(さくら/エックスサーバー対応スクリプトを公開しました)


2026年9月22日、WordPress本体の重大な脆弱性 CVE-2026-87902 の修正版が公開されました。未認証(ログイン不要)で悪用できるパストラバーサルの不具合で、公開からわずか数時間で世界中のサイトへの攻撃(偵察)が始まり、その翌日には実際の侵害まで確認されています。

対策の答えはシンプルで、WordPress本体を修正版へ更新すること。これが最優先で、これに勝る対策はありません。ただ保守の現場では、更新を終えたあとに「公開から更新までの間に、うちのサイトは狙われていなかったか?」を確かめたい場面が必ず出てきます。

そこで、レンタルサーバーのアクセスログから今回の攻撃の痕跡を探すシェルスクリプトを作り、OSSとして公開しました。この記事では脆弱性の中身をやさしく整理したうえで、さくらインターネット版・エックスサーバー版それぞれの使い方と、結果の読み方までをまとめます。

CVE-2026-87902 とは

WordPress本体の「page-template(ページテンプレート)解決処理」に見つかった、未認証で悪用できるパストラバーサルの脆弱性です(分類は CWE-98:include/require に渡すファイル名の不備)。

WordPressはページを表示するとき、get_page_template() という関数で「どのPHPファイルで描くか」を選びます。本来その対象はアクティブなテーマのフォルダ内に限られます。ところがこの不具合では、細工したリクエストによって ../(親フォルダへさかのぼる記法)を使い、**テーマの外にある任意の「読み取り可能な .php ファイル」を include(読み込み・実行)**させられてしまいます。

さらに、サーバー環境とテーマ構成の条件が揃うと、これがリモートコード実行(RCE)=サイトの乗っ取りにまで発展します。成立条件の一つとして「アクティブな親/子テーマのトップ階層フォルダ名が page- で始まること」が挙げられています。

本記事は防御・啓発を目的としているため、悪用を助長する具体的な攻撃コードやペイロードは掲載していません。

影響範囲と深刻度

項目内容
影響バージョンWordPress 4.7.0 〜 7.1.1
修正版7.1.2(旧ブランチにもバックポート。古いものは 4.7 系までカバー)
公開日2026年9月22日
深刻度CVSS 8.1(High)〜 9.2(Critical)※評価機関により幅がある

特に警戒すべきは、悪用が始まる速さです。セキュリティ企業 Patchstack は、修正版の公開から約5時間後には偵察目的のアクセスを観測し、その翌日(9月23日)には実際の侵害へ拡大、攻撃者が /tmp や /var/tmp に悪性のPHPファイルを書き込んでシェルコマンドを実行する段階まで進んだと報告しています。「未認証・悪用が進行中・PoC(実証コード)が公開済み」の三拍子がそろっており、対応を先延ばしにできない状況です。

最優先の対策は「WordPress本体の更新」

まず何よりも、WordPressを修正版へ更新してください。これが唯一かつ最大の根本対策です。

  • 管理画面の「更新」から、または各サーバーの自動更新設定で最新へ上げる
  • 強制自動更新が働いていても、実際にバージョン番号が上がっているかを必ず確認する
  • WAF(Wordfence やサーバー側WAF など)は更新までの時間を稼ぐ緩和策であって、更新の代わりにはならない

それでも「狙われていなかったか」を確認したい

更新を終えても、公開から更新までの空白期間に自分のサイトが攻撃を受けていなかったか、気になるはずです。今回の攻撃はパストラバーサルの痕跡(../ などの文字列)がリクエストに含まれるため、アクセスログを見れば試行の跡を探せます。

国内の主要レンタルサーバーはSSHでアクセスログを参照できます。そこで、ログから今回の痕跡を機械的に洗い出すシェルスクリプトを作り、OSSとして公開しました。

公開したスクリプト(OSS)

GitHub の web-soudan/wp-security-audit-on-jp-hosting に、以下の2本を追加しました。検知ロジックは共通で、対象ログの探し方だけがサーバーごとに異なります。

  • check-cve-2026-87902-sakura.sh … さくらインターネット向け
  • check-cve-2026-87902-xserver.sh … エックスサーバー向け

検知できること

  • アクセスログ中のパストラバーサル痕跡(../、..%2f、%2e%2e/、..\ など、URLエンコード形も含む)
  • そのうち pearcmd・php:// などのPHPラッパー・/tmp /var/tmp への書き込みを伴う「高シグナル」な行は [!] 付きで強調

検知できないこと(ここが重要)

  • マッチ=侵害成立ではありません。 現在観測されているのは主に「試行・偵察」で、リクエストが一致してもコード実行や侵害が成立した証拠にはなりません。あくまで「要調査」のサインです。
  • マッチなし=安全でもありません。 POST経由・ログのローテーション済み・対象範囲外などで痕跡が残らないこともあります。

使い方:さくらインターネット版

SSHでサーバーに接続し、ホームディレクトリで実行します。~/log/access_*.gz と未圧縮の当日ログをまとめて対象にします。

# 対話実行(過去何日分か聞かれる。Enterで14日)
./check-cve-2026-87902-sakura.sh

# 過去14日分を非対話で(第1引数の空文字は「既定パターン」の意味)
./check-cve-2026-87902-sakura.sh "" 14

# ダウンロードしてそのまま実行
curl -s https://raw.githubusercontent.com/web-soudan/wp-security-audit-on-jp-hosting/main/check-cve-2026-87902-sakura.sh | bash -s -- "" 14

実行すると、対象ファイルと検知パターンが表示され、最後に「トラバーサル痕のヒット件数」と「うち高シグナル [!] 行」が出ます。まずは [!] の行から重点的に確認してください。

使い方:エックスサーバー版

エックスサーバーはドメインごとに ~/ドメイン名/public_html(公開フォルダ)と ~/ドメイン名/log/(ログ)に分かれています。スクリプトは public_html を再帰的に探してドメインを自動特定し、各ドメインの log/ にある ドメイン名.access_log_*(gz+未圧縮)を対象にします。複数ドメインを一度にまとめてチェックできます。

# 対話実行
./check-cve-2026-87902-xserver.sh

# 過去14日分を非対話で
./check-cve-2026-87902-xserver.sh "" 14

# ダウンロードしてそのまま実行
curl -s https://raw.githubusercontent.com/web-soudan/wp-security-audit-on-jp-hosting/main/check-cve-2026-87902-xserver.sh | bash -s -- "" 14

検知パターンや出力の見方はさくら版とまったく同じです。

結果の読み方と、ヒットした場合の調査手順

ヒットが0件だったとき … このログ範囲では痕跡は見つからなかった、という意味です。ただし前述のとおり安全の保証ではないので、修正版へ更新済みであることの確認は必ず行ってください。

ヒットがあったとき … 攻撃の「試行痕跡」です。侵害の確定ではありませんが、次の手順で調査を進めます。

  1. WordPress本体が修正版になっているか確認する(未対応なら最優先で更新)
  2. wp-content/uploads や公開ディレクトリに、身に覚えのない .php が無いか確認する(Webシェル設置の兆候)
  3. [!] 行の送信元IP・時刻・レスポンスコードを精査し、必要ならIPを遮断する
  4. 侵害が疑われる場合は、DBパスワードやAPIキーなど読み取られた可能性のある認証情報をローテーションする

恒久対策とまとめ

「公開から数時間で攻撃が始まる」今回のようなケースでは、日頃の備えがそのまま被害の差になります。

  • 本体・テーマ・プラグインの更新を継続的に回す(自動更新+定期確認)
  • いつでも復元できるバックアップを確保しておく
  • WAFで攻撃の初期段階を緩和する
  • アクセスログを定期的に見る/今回のようなスクリプトで素早く点検する

まとめると、①まず更新 → ②ログで試行痕跡を確認 → ③痕跡があれば侵害調査、の順で動くのが基本です。

WordPressの保守は「Webの相談所」へ

Webの相談所では、WordPressサイトの継続的な更新・監視・脆弱性対応を代行しています。今回のような重大な脆弱性が出たときの緊急対応や、複数サイトの一括点検もお任せいただけます。「更新が追いつかない」「うちのサイトは大丈夫か不安」という方は、お気軽にご相談ください。

免責事項

本スクリプトは現状有姿(as-is)で提供され、検出結果や安全性を保証するものではありません。実行はご自身の責任でお願いします。まずはバックアップのある状態や検証環境でお試しいただくことを推奨します。

参考・出典