こんにちは。せっかくのシルバーウィークなのに、台風で行きたかった海に行けず、少し残念な気持ちのオレンジソフトウェアの藤田です。
そんな連休明け早々、気になったのがWordPressの脆弱性のニュースです。今回取り上げるのは、9月22日に公表された「CVE-2026-87902」。WordPressを使っている方は、確認しておきたい内容です。
オレンジソフトウェアでは、多くのWordPressサイトが稼働するサーバーを管理しています。私たちにとっても他人事ではないので、どんな問題なのか、何を確認すればよいのかを、サーバーを管理する立場からまとめました。
まず確認したいのは、WordPress本体に修正が適用されているかどうかです。 使用するテーマやサーバーの条件によっては、不正なコードの実行につながる可能性があります。WordPress公式は、修正版への速やかな更新を推奨しています。WordPress公式リリース告知
本記事について・免責事項
本記事は、2026年9月24日時点の公開情報をもとにした一般的な解説です。個別サイトの安全性、侵害の有無、対策の有効性や復旧を保証するものではありません。実際の対応は、最新の公式情報とご利用環境を確認し、バックアップや業務への影響を考慮したうえで、管理者・保守会社とご判断ください。オレンジソフトウェアが受託する作業の範囲・条件は、個別の契約に従います。
CVE-2026-87902とは?
WordPressがページのテンプレートを選ぶ処理にある、ファイルの読み込み先を適切に制限できない問題です。 攻撃者がログインしていなくても、使用中のテーマの外にある、サーバー上のPHPファイルを読み込ませる可能性があります。
問題となるのは、get_page_template() という処理です。テーマとサーバー環境の条件によっては、外部の攻撃者がサーバー上で不正なプログラムを動かす「リモートコード実行(RCE)」につながります。
WordPress公式アドバイザリでは、**CVSS v4.0で9.2(Critical)**と評価しています。一方、シンガポールのCyber Security Agency(CSA)はCVSS v3.1で8.1(High)と案内しています。評価方式が異なるため、数値と区分に違いがあります。WordPress公式アドバイザリ・CSAの注意喚起
2026年9月24日時点で、すでに実際の悪用が報告されています。更新は緊急対応として進めてください。 CSAも、悪用の報告と実証コード(PoC)の公開を注意喚起しています。CSAの注意喚起
Patchstackの報告では、攻撃は「読み込みの確認」「PEARへの到達確認」「PHPファイルの書き込み」へ進んでいます。単なる探索段階として扱う状況ではありません。ただし、個別サイトで侵害が成功したかは、別途調査が必要です。Patchstackの観測報告(英語)
発見者のRobert Ressl氏も、実証コード(PoC)を公開したことを説明しています。管理サイトの確認と修正適用を優先したい状況です。発見者による解説(英語)
自社のWordPressサイトも影響する?
影響を判断するには、WordPress本体のバージョン、使用中のテーマ、サーバー側の条件を確認します。サイトの見た目や、管理画面にログインできるかどうかだけでは判断できません。
公式アドバイザリと発見者の解析を合わせると、確認すべき条件は次のとおりです。影響条件の公式説明・発見者による詳細な条件の説明
- 使用中の親テーマまたは子テーマの直下に、
page-templatesなど名前がpage-で始まるフォルダーがある。 - 読み込み対象のPHPファイルがサーバー上に存在し、Webサーバーの実行アカウントから読み取れる。
-
page_idで選択できる、未ログインでも閲覧可能な公開済み固定ページがある。 - 有効なカスタムテンプレートの指定によって、問題の処理より前にテンプレートが確定しない。
- ファイルシステムのアクセス制限などが、対象ファイルの読み込みを妨げない。
テーマを確認する際は、有効な親テーマ・子テーマの直下にあるフォルダーを調べます。page-about.php のようなファイルがあるだけでは、このフォルダー条件には当たりません。公式はTwenty TwelveやTwenty Fourteenなどを例示しています。一方、発見者が調べたTwenty Twenty-Three/Four/Fiveのバージョンには該当フォルダーがなく、検証時に追加したと説明しています。テーマ名だけで安全性を判断せず、実際の構成と修正状況を確認してください。
さらに、不正なコード実行に至るかは、読み込まれるPHPファイルの内容とサーバー設定にも左右されます。「テーマ外のファイルを読み込めること」と「攻撃者が任意のコードを実行できること」は区別する必要があります。
そのため、未修正のWordPressを使っているすべてのサイトで、直ちにコード実行が成立するわけではありません。ただし、条件が分からないまま「自社は大丈夫」と判断せず、修正版への更新を進めることが重要です。WordPress公式アドバイザリ
ホームページの担当者は、まず管理会社に次の情報を確認してください。
- 現在のWordPress本体のバージョンと、この脆弱性の修正適用状況
- 使用中のテーマと親テーマの名称
- サーバーやWordPressの更新を担当する会社・担当者
- 最後にバックアップと動作確認を行った時期
対策の基本は、WordPress本体の修正版への更新
今回の修正対象はWordPress本体です。プラグインだけを更新しても、本体の修正を適用したことにはなりません。 2026年9月22日に公開されたWordPress 7.1.2で修正され、旧系列にも修正が提供されています。WordPress公式リリース告知
主な系列で、この脆弱性を修正したバージョンは次のとおりです。2026年9月24日時点の情報であり、閲覧時点の最新版を示す表ではありません。
| 利用している系列 | この脆弱性の修正版 |
|---|---|
| 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 |
表は代表的な系列の抜粋です。修正は4.7系まで提供されています。その他の系列は、公式アドバイザリの修正版一覧をご確認ください。
「7.1.2より小さい番号だから、すべて未修正」という判断はできません。 一方、旧系列への今回の修正提供は、その系列が今後も積極的にサポートされることを意味しません。WordPress公式は、積極的なサポート対象は最新バージョンのみと説明しています。今回の対応と合わせて、古い環境を継続利用する方針も見直しましょう。WordPress公式のバックポート説明
サーバー管理の現場で大切なのは、更新前後の確認
更新ボタンを押したら、実際のバージョンと主要な機能まで確かめます。管理対象が多いほど、更新漏れを防ぐ記録も重要になります。
flowchart TD
A["管理サイトと修正適用状況を把握"] --> B{"侵害を疑う兆候はあるか"}
B -->|見つかっていない| C["バックアップ・復元手順を確認"]
C --> D["修正版へ更新"]
D --> E["バージョン・主要機能・ログを確認"]
E --> F["結果を記録し、継続して監視"]
B -->|ある| G["被害拡大を防止・ログ等を保全"]
G --> H["調査と並行して修正・必要な復旧を進める"]
H --> E
通常は、管理対象の把握、バックアップの確認、更新、動作確認の順に進めます。侵害が疑われる場合は、ログなどを保全しながら被害拡大を抑え、調査と修正・復旧を組み合わせます。調査完了を待ってアクセス制限や修正を先延ばしにせず、管理者と手順を決めて並行して進めます。 目立った兆候がなくても、侵害がないとは断定できません。
1.管理しているWordPressを一覧にする
複数のサイトを運用している場合は、更新漏れを防ぐため、管理対象を一覧にします。会社のメインサイトだけでなく、採用サイト、キャンペーンサイト、旧サイト、公開された検証環境なども確認対象です。
サイトごとにバージョン、担当者、更新日時、確認結果を残しておくと、未対応のサイトが分かります。
2.バックアップと復元方法を確認する
更新前には、ファイルとデータベースの両方について、バックアップの取得状況と復元方法を確認します。バックアップが存在するだけでなく、どの時点へ戻せるか、誰が復元できるかも大切です。
予約や注文など、新しいデータが増え続けるサイトでは、復元によって直近のデータを失わないよう、作業時刻や運用方法も調整します。侵害が疑われる場合は、現在のバックアップを「安全な復元元」とは扱わず、調査用の保存と、正常な状態への復旧を分けて考えます。
3.修正版の適用と、適用後のバージョンを確認する
更新操作の後は、実際のバージョンまで確認します。自動更新を有効にしていても、実行待ちや失敗などで未適用の可能性があるためです。
テーマやプラグインとの互換性を確認しながら、修正適用を速やかに進めます。すぐに更新できない事情がある場合は、管理会社と公開範囲の制限などの暫定対応を検討し、更新までの予定を決めます。暫定対応で修正版への更新を代替できるとは限りません。
4.見た目だけでなく、業務に必要な機能をテストする
更新後は、トップページの表示に加えて、お客様が実際に使う機能を確認します。問い合わせや注文が受け付けられなければ、ページが表示されていても業務に支障が出るためです。
| 確認する場所 | 確認例 |
|---|---|
| 公開ページ | 主要ページ、メニュー、画像、スマートフォン表示 |
| 問い合わせフォーム | 送信完了、管理者への通知、確認メール |
| 予約・会員機能 | 予約、ログイン、閲覧権限、登録情報の表示 |
| EC・決済機能 | 注文の流れと連携状態。誤課金を避ける条件で確認 |
| 管理画面 | 記事編集、画像アップロード、必要な設定画面 |
| サーバー | エラーログ、応答状況、不審なアクセスや変更 |
管理者向け:更新と合わせて確認したいPHP設定
register_argc_argv の無効化や不要なPEARの除去は、実証されたコード実行経路を断つ緩和策です。WordPress本体の修正に代わるものではありません。
発見者が実証した経路は、読み取り可能な pearcmd.php と関連ファイル、Webリクエストを処理するPHPでの register_argc_argv=On、書き込み可能な出力先などに依存します。発見者の実証条件・緩和策
管理者は利用中のアプリへの影響を確認し、不要であれば、Web側のPHP設定を次の値に変更することを検討してください。
register_argc_argv = Off
確認するのは、そのサイトのWebリクエストに適用される設定です。コマンドライン用PHPでOffでも、PHP-FPMやApache側で同じとは限りません。設定の反映に必要な再読み込み等を行い、反映結果とサイトの動作を確認します。確認用の設定情報を一般公開したままにしないよう注意してください。
PEARを除去する場合も、他のアプリが利用していないかを先に確認します。これらの変更後も、テーマ外のファイルを読み込める不備自体は残るため、修正版への更新を進めてください。
更新すれば、すべての対応が終わるわけではありません
脆弱性の修正と、すでに侵害されたサイトの復旧は別です。 修正版へ更新しても、侵入後に追加された不正ファイルやアカウントが自動的に除去されるとは限りません。
例えば、見覚えのない管理者アカウント、不審なPHPファイル、説明のつかないファイル変更、意図しない転送や外部通信は、調査が必要な兆候です。ただし、こうした兆候だけで今回のCVEが原因と断定することもできません。
侵害が疑われる場合は、必要に応じてアクセスを制限し、ログやファイルの状態を保全したうえで、侵入経路と影響範囲を調べます。その結果に応じて、安全な状態からの再構築や復元、漏えいの可能性がある認証情報の変更などを検討します。
バックアップから復元する場合も、再公開前に脆弱性の修正と侵入経路への対処を行います。復元元が侵害前の正常な状態かどうかも確認してください。
ニュージーランドのNCSCも、修正版の適用に加え、不正アクセスや侵害の調査を呼びかけています。NCSCの注意喚起
管理者向け:ログとファイルの調査指標
攻撃リクエストの痕跡と、読み込み・書き込みが成功した証拠を分けて確認します。 Patchstackが示す主な調査指標を以下にまとめます。検出指標と緩和策の出典
| 調査対象 | 確認する指標 |
|---|---|
| クエリ文字列・記録されているPOST本文 | pagename 内の %2e%2e、%252e%252e。大文字・小文字の違いにも注意 |
| パラメーターの組み合わせ | templates%2f などで始まる pagename、同一リクエスト内の pagename と page_id |
| PEAR関連のアクセス | pearcmd、+config-show、+config-create |
| User-Agent | cve-2026-87902-poc/1.0、nuclei-cve-2026-87902/1.0 |
| サーバー内のファイル | /tmp・/var/tmp の不審なPHPファイル。報告例は poc87902.php など |
User-Agentは変更できるため、上記の文字列がないことは安全の証明になりません。送信元IPの遮断だけに頼らず、修正を適用します。
通常のページURLへの不審なリクエストで、200応答とともに、本来返らないOPML・RSS本文が返った記録は、読み込み成功を示す重要な証拠です。200というステータスだけで判断せず、レスポンス本文とリクエストの対応を確認してください。読み込み成功は脆弱な状態だった証拠ですが、それだけで任意コード実行まで確認したことにはなりません。
一般的なアクセスログにはPOST本文やレスポンス本文が残らない場合があります。保存済みのWAF・監視記録などと照合し、記録がない場合は「判定できない」と扱います。
不審なPHPファイルは、正規の処理で作られたものか、内容・作成時刻・関連ログを確認します。攻撃による書き込みが確認できた場合は、侵害として対応します。 調査前に実行したり削除したりせず、証拠を保全して、前述の制限・調査・復旧を進めてください。
WordPressを安全に使い続けるには、継続的な保守が必要
今回の修正を適用した後も、本体・プラグイン・サーバーの保守は続きます。担当者を決め、次の項目を定期的に点検しましょう。
| 管理する対象 | 継続して確認すること |
|---|---|
| WordPress本体 | セキュリティ情報、更新状況、更新後の動作 |
| テーマ・プラグイン | 更新提供の有無、互換性、不要なものの整理 |
| PHP・サーバーOS | サポート状況、セキュリティ更新、設定 |
| アカウント・権限 | 不要なアカウント、管理者権限、認証方法 |
| バックアップ | 取得結果、保存先、復元可能性 |
| ログ・稼働状況 | 異常や不審な操作の把握、障害時の連絡体制 |
特に確認したいのが、「誰がどこまで管理しているか」です。レンタルサーバーの契約があっても、WordPress本体やプラグインの更新までサービスに含まれているとは限りません。制作会社、サーバー会社、自社担当者の役割を整理しておきましょう。
オレンジソフトウェアは、開発とサーバー管理の両面から支援
株式会社オレンジソフトウェアは、WordPressサーバーの管理に加え、Webシステム開発、サーバー・ネットワークの構築と管理を行っています。
例えば、更新後に問い合わせメールが届かなくなった場合は、フォームの処理、PHPのエラー、メール送信設定などを確認します。WordPressの画面から分かることに加え、サーバー側のログや設定も調べて原因を絞り込みます。
自社サービスの開発・運営と受託開発の経験をもとに、予約や会員機能などを持つサイトの運用もご相談いただけます。調査・更新・復旧・保守の対応範囲は、サイトの状態と契約内容を確認してご案内します。
よくある質問(Q&A)
Q.サイトが普通に表示されていても、確認は必要ですか?
はい。見た目では判断できないため、本体のバージョンと修正適用状況を確認してください。
Q.プラグインやテーマの更新だけで対策できますか?
本体の修正適用が必要です。プラグインやテーマだけの更新では完了しません。
Q.自動更新を有効にしていれば大丈夫ですか?
自動更新は有効な備えですが、設定や環境によって実行されない・遅れる場合があります。実際のバージョンと主要機能の動作を確認してください。また、更新前に侵入されていた場合、不正ファイルやアカウントなどが残っている可能性があり、別途調査が必要です。
Q.古いWordPressでも修正できますか?
今回の修正は4.7系まで提供されています。使用中の系列に合う修正版を確認し、古い環境からの移行も検討してください。
Q.更新すると、表示や機能が崩れることはありますか?
互換性の問題が出る可能性はあります。バックアップと復元方法を確かめ、管理会社と更新・動作確認の手順を決めましょう。
Q.すでに不正アクセスされていた場合、更新だけで直りますか?
更新後も不正なファイルやアカウントが残る場合があります。侵害の範囲を調べ、必要な復旧を行います。
Q.他社が制作したサイトでも相談できますか?
ご相談いただけます。管理権限や既存の保守契約を確認して、対応できる範囲をご案内します。
Q.調査や更新には、いくらかかりますか?
サイト数、環境、調査・復旧の必要性によって異なります。状態を伺い、作業範囲とお見積もりをご案内します。
管理状況が分からない場合は、まず確認から
「誰が更新しているか分からない」「制作してから何年も見直していない」という場合も、オレンジソフトウェアへご相談ください。
お問い合わせの際は、サイトのURL、分かる範囲のWordPressバージョン、サーバー会社、気になっている症状をお知らせください。パスワードなどの秘密情報は、初回のお問い合わせ本文に記載する必要はありません。
執筆:株式会社オレンジソフトウェア
大阪府大阪市中央区瓦町4-3-14-812。Webシステム開発、ホームページ制作、サーバー・ネットワークの構築・管理、AI活用支援を提供しています。会社概要
