【ITニュース解説】WordPress CVE-2026-87902: an Unauthenticated Path Traversal That Escalates into Remote Code Execution

WordPressのシステムにおいて、極めて深刻なセキュリティ上の欠陥が発見され、その悪用がすぐに始まったというニュースが報じられた。この脆弱性は「CVE-2026-87902」という識別番号がつけられており、システムの根幹に関わる問題だ。セキュリティの深刻度を示すCVSSスコアでは9.2という高い値がつけられている。これは、誰でも、特別な認証なしに、またユーザーが何らかの操作をする必要もなく悪用できてしまう、非常に危険な脆弱性であることを意味する。具体的には、「パス・トラバーサル」と呼ばれる種類の問題が、WordPressのテンプレートファイルを決定するロジックの中に潜んでいた。報道によると、2026年9月22日には最初の悪用が確認され、その後も多数の攻撃が記録されている。

この問題は、WordPressがウェブページを表示するために、どの「テーマファイル」を使うかを決めるget_page_template()という関数に起因する。通常、ウェブサイトのデザインやレイアウトを管理するテーマファイルは、特定のディレクトリ内に配置されている。しかし、この関数が要求されたテンプレート名をファイルシステム上で解決する際、許可されたファイルだけを厳密にチェックする「許可リスト」を使うのではなく、要求された名前をそのままファイルシステムのパスとして扱ってしまった。その結果、攻撃者は細工したリクエストを送ることで、テーマディレクトリの外側にある、本来アクセスできないはずのファイルをWordPressに読み込ませることが可能になった。これは「ローカル・ファイル・インクルージョン」と呼ばれる種類の脆弱性であり、攻撃者にとってはそのサーバー上にある「都合の良いファイル」を探し出して利用する足がかりとなる。この脆弱性は、WordPressのバージョン4.7.0から7.1.1までに影響を及ぼす。すでにパッチが提供されており、バージョン7.1.2、7.0.6、6.9.9で修正されたほか、古い4.7系ブランチ向けにも4.7.37というバージョンが提供されている。

攻撃は、単にサーバー上のファイルを読み込むだけで終わらない。この脆弱性を悪用することで、攻撃者は「リモート・コード実行」、つまり遠隔地からサーバー上で任意のプログラムを実行することに成功している。その攻撃の仕組みは次の通りだ。まず、攻撃者は脆弱性を利用して、多くのPHPインストールに標準で同梱されているpearcmd.phpというヘルパーファイルをWordPressに読み込ませる。PHPの実行環境においてregister_argc_argvという設定が有効になっている場合、pearcmd.phpは、リクエストで渡された引数をコマンドとして解釈し、実行してしまう性質がある。つまり、この脆弱性によってpearcmd.phpがウェブアプリケーションの一部として読み込まれると、攻撃者は引数を通して好きなコマンドをサーバーに実行させることができるようになるのだ。さらに、攻撃者が実行したい悪意のあるファイルを一時的にサーバーに置く（「ステージング」する）場所も必要となるが、観測された攻撃では、page-*というパターンに一致する名前を持つテーマディレクトリなど、書き込み可能な場所が利用されている。

実際に観測された攻撃活動では、wp-pear-rce-flag.phpやpoc87902.phpといったファイル名、あるいはluci_やzeta_といった接頭辞を持つドロッパー（悪意のあるプログラムをダウンロード・実行させるファイル）が検出されている。これらの特徴は、特定のターゲットを狙った攻撃というよりも、インターネット全体を対象とした広範なスキャン活動によく見られるものだ。このような広範なスキャンは、多くの場合、その後すぐに特定の脆弱性を狙った、より高度な自動化された攻撃へと発展する傾向がある。そのため、パッチを適用できる期間は非常に短いことを認識する必要がある。

システム管理者やウェブサイトの運営者にとって、最も重要な防御策は、何よりもまず「パッチを適用すること」である。WordPressのバージョンを7.1.2、7.0.6、6.9.9のいずれかにアップデートすることで、このパス・トラバーサルの脆弱性は完全に解消される。また、もし古い4.7系バージョンを使用している場合は、4.7.37にアップデートする必要がある。この脆弱性は認証なしで悪用できてしまうため、通常の定期的なアップデートではなく、緊急性の高い対応として、迅速に実施することが求められる。

もし、パッチを適用する前にウェブサイトがこの脆弱性にさらされていた可能性がある場合、単にアップデートするだけでは不十分で、適切な「インシデント・レスポンス」（事件発生時の対応）も必要となる。具体的には、前述の不審なファイル名パターンを持つファイルがウェブサイトのルートディレクトリ内に存在しないか、テーマディレクトリに見慣れないエントリーがないか、あるいは正規のプラグインが通常書き込まないようなPHPファイルがアップロードやメディアのパス下に存在しないかなどを確認する。さらに、ウェブサーバーのアクセスログを詳しく調べ、攻撃が確認された期間周辺で、テンプレートパラメータに../のような「パス・トラバーサル」を示すシーケンスが含まれるリクエストがないかを確認することも重要だ。

追加の防御策として、二つの設定変更も検討できる。一つは、もしサーバー上でpearcmd.phpのようなPEARヘルパーファイルが不要であれば、それらを削除することだ。これにより、攻撃がリモート・コード実行にエスカレートする経路を大幅に狭めることができる。もう一つは、本番環境のPHP実行環境でregister_argc_argvという設定を無効にすることだ。これにより、引数によるコマンド実行のステップを阻止できる。しかし、この設定変更は他のウェブアプリケーションにも影響を与える可能性があるため、実際に導入する前に十分なテストを行うことが不可欠である。ただし、これらの設定変更はあくまで補助的な対策であり、脆弱性そのものを修正するパッチの代わりにはならないことを理解しておく必要がある。

最後に、テーマやプラグインのアップデートをまとめてテストできる「ステージング環境」（本番環境とは別のテスト用の環境）を常に準備しておくことの重要性を強調したい。テストされていない依存関係があるために、システム管理者が迅速にパッチを適用できない場合、ウェブサイトは何週間も脆弱な状態にさらされ続けることになる。今回のニュースが示すように、この特定の脆弱性はすでにインターネット上で活発に悪用されているため、迅速な対応が不可欠だ。