WordPress本体に未認証で任意コード実行の恐れ（CVE-2026-87902）悪用を確認、4.7系以降は今すぐ更新を
WordPress本体に、ログインしていない攻撃者がサーバー上のPHPファイルを読み込ませ、条件がそろえば任意のコードを実行できる脆弱性（CVE-2026-87902、CVSS 9.2）が見つかった。WordPressは2026年9月22日に修正版を公開したが、同じ日のうちに攻撃が観測されている。米CISAは9月25日、悪用が確認された脆弱性の一覧（KEV）に追加した。影響は4.7.0から7.1.1までと非常に広い。プラグインではなく本体の欠陥なので、自社サイトをWordPressで運営している企業は、制作会社任せにせず更新状況を確かめてほしい。
背景
WordPressのセキュリティ勧告（GHSA-7hp8-65ch-5whp）によると、問題はページテンプレートを決める処理にある。攻撃者は、有効なテーマのフォルダの外にあるPHPファイルを読み込ませることができる。脆弱性の種類は、PHPのinclude/require文に渡すファイル名の制御不備（CWE-98）である。攻撃が成立するには条件があり、有効な親テーマまたは子テーマの直下に「page-」で始まるフォルダがあることが必要になる。勧告は該当する例としてTwenty Twelve、Twenty Fourteen、Neve、Hestia、Sydneyを挙げている。さらに、読み込める位置にPHPファイルがあることも条件になる。PHPのregister_argc_argvが有効な環境では、PEARに付属するpearcmd.phpを足がかりにコード実行まで進める。勧告は、公式のDocker用PHPイメージや、PHP 8.5より前のcPanelの標準設定がこれに当たるとしている。
修正版は7.1.2、7.0.6、6.9.9、6.8.10のほか、4.7系の4.7.37まで各系統に出ている。勧告に回避策の記載はなく、更新が唯一の対処である。
リスクの全体像
海外のセキュリティ企業の観測では、攻撃は修正版の公開と同じ9月22日の11時49分（協定世界時）に始まった。Patchstackは、様子見の探索から実際の攻撃へ移っていく経過を報告している。報道によると、攻撃のリクエストは /usr/local/lib/php/pearcmd.php を狙い、/tmp/ や /var/tmp/ にファイルを書き込んでいた。外部からファイルを送り込むためのPHPスクリプトを読み込ませる例や、wp-pear-rce-flag.php、poc87902.php といった名前のファイルを作る例も見つかっている。コードを実行されると、サイトの改ざん、偽のログイン画面やマルウェア配布ページの設置、データベースに保存された問い合わせや会員の情報の持ち出しにつながる。
WordPressは、マイナーリリースとセキュリティ修正を自動で適用する設定が初期状態で有効になっている。そのため実際の被害は限られるという見方もある。ただし、制作会社が表示崩れを嫌って自動更新を止めているサイトや、古い系統のまま放置されたサイトでは、修正が当たっていない。中小企業のサイトほど、この状態に気づく人が社内にいない。
チェックリスト
- 管理画面の「ダッシュボード」→「更新」で、WordPressのバージョンが修正版（7.1.2、7.0.6、6.9.9、6.8.10など各系統の最新）になっているか
- 自動更新が止められていないか。wp-config.php で WP_AUTO_UPDATE_CORE が false になっていないか
- 使っているテーマ（子テーマを含む）の直下に「page-」で始まるフォルダがあるか
- サーバーのPHPで register_argc_argv が有効になっていないか（レンタルサーバーなら事業者に確認する）
- WordPressのフォルダや /tmp/ に、wp-pear-rce-flag.php、poc87902.php、luci_ や zeta_ で始まる見覚えのないPHPファイルが無いか
- アクセスログに pearcmd.php を含むリクエストが残っていないか
打ち手
1番目は更新である。管理画面から本体を各系統の修正版に上げる。制作会社や保守会社に運用を任せている場合は、修正版の適用日と、自動更新の設定状況を文書で確認する。2番目は侵害調査で、上のチェックリストのファイルとログを確認する。不審なファイルが見つかった場合は、サイトを一時的にメンテナンス表示に切り替え、保守会社やセキュリティの専門会社に調査を依頼する。あわせて管理者アカウントのパスワード、データベースのパスワード、FTPやSSHの認証情報を変更する。3番目は再発の防止で、自動更新を有効にしておくこと、使っていないテーマとプラグインを削除すること、PHPのバージョンと設定をレンタルサーバー事業者の推奨に合わせることを運用ルールにする。共有ホスティングのcPanel環境を使っている場合は、PHPの設定を自分で変えられるかも確認しておく。
本体の更新は、サイトの持ち主が自分で確かめる
あわせて読みたい
- WordPress脆弱性 2026年1-3月 ― AIプラグインが攻撃経路に
- 【要確認】LiteSpeed cPanelプラグインのシンボリックリンク脆弱性 CVE-2026-54420（CVSS 8.5）― 共有ホスティングでの権限昇格、実際に悪用
- ムラウチドットコムで771万件の個人情報漏えい — Webシステムの脆弱性1つから複数システムへ広がった経緯
- 23万件が漏えいしたECサイト不正アクセス ― パスワードのハッシュ化では守れないもの
Omamori AI の結論
- 事実: WordPress本体のCVE-2026-87902（CVSS 9.2）は、ログインなしでサーバー上のPHPファイルを読み込ませ、条件次第でコードを実行できる。影響は4.7.0〜7.1.1。修正版は9月22日に公開され、同日から攻撃が観測された。CISAは9月25日にKEVへ追加した。
- 判断軸: 攻撃には条件があるが、自社サイトが条件に当たるかを短時間で判断できる企業は少ない。条件を調べるより先に更新し、そのあと侵害の痕跡を確かめる。
- 打ち手: 各系統の修正版への更新、自動更新の設定確認、不審なPHPファイルとログの確認、痕跡があれば認証情報の変更と専門家への調査依頼。
経営者視点で考えるべきこと
会社のWebサイトは、公開した時点で制作会社との契約が終わり、更新の担当が決まっていないことが多い。その状態で本体に深刻な脆弱性が出ると、誰も気づかないまま改ざんの入口になる。経営者が確認したい点は3つある。自社サイトのWordPressを更新する責任者が、社内か保守契約のどちらかで決まっているか。保守契約に、悪用が確認された脆弱性への対応期限が書かれているか。サイトの問い合わせフォームや会員機能に、顧客の個人情報が保存されていないか。改ざんされたサイトが取引先や顧客にマルウェアを配れば、謝罪と調査、サイトの作り直しに追われ、その間は問い合わせの窓口も止まる。更新の担当を決めておけば、その多くは避けられる。
