認証されていない攻撃者によるリモートコード実行を許してしまうこの脆弱性は、多くの企業が自社のWordPressサイトすべてを把握していないという点で特に危険です。
WordPressは、認証されていない攻撃者に完全なリモートコード実行（RCE）能力を与えてしまう重大な深刻度のセキュリティ脆弱性を修正したと発表しました。すでに実際の攻撃事例も報告されています。
その人気の高さゆえに、WordPressはたびたび攻撃の標的となってきました。7月にもRCEを許してしまう最大深刻度のバグを修正しています。WordPressによると、今回CVE-2026-87902として追跡されているこの脆弱性は、スイスを拠点とするセキュリティ研究者のRobert Ressl氏（LinkedInプロフィール）によって発見・報告されたものです。
WordPress 7.1.2セキュリティリリースの発表投稿によれば、今回の修正は「認証されていない攻撃者が、特定の条件下でページテンプレートの解決処理を操作し、アクティブなテーマディレクトリ外にある任意の読み取り可能なローカルPHPファイルを読み込ませることができる」という問題に対応するものです。「サーバー環境とアクティブなテーマの双方について該当する前提条件が満たされている場合、これによりリモートコード実行（RCE）につながる可能性があります」としています。
WordPressはユーザーに対し、ただちにサイトを更新するよう強く呼びかけています。またこの脆弱性は多くの旧バージョンのWordPressにも影響するため、修正はバージョン4.7までバックポートされたとのことです。
Digital 520のプリンシパルコンサルタントであるNoah Kenney氏（LinkedInプロフィール）は、この脆弱性で最も懸念しているのは、攻撃者が引き起こせる被害の規模の大きさだと述べています。
「攻撃者がひとたびPHPの実行権限を手にすれば、wp-config.phpを読み取ってデータベースの認証情報や認証キーを取得し、管理者アカウントを作成し、決済フォームやリード獲得フォームを改ざんし、訪問者をリダイレクトさせ、さらには永続的なコードをインストールすることも可能になります」と同氏は語ります。「見落とされがちなのは、攻撃者がそこに至るまでの経路です。Pearcmd.php自体は正規のPHPパッケージ管理ツールですが、攻撃者はその設定コマンドを悪用して、任意の内容をディスクに書き込むことができます。現在確認されている攻撃では、これを使って悪意あるPHPを/tmpに設置したうえで、今回のWordPressの脆弱性を利用してそのファイルを読み込み・実行しています。WordPressのディレクトリの変更だけを監視しているセキュリティチームでは、この最初の段階を丸ごと見逃してしまう可能性があります」
新たなリスクの現実
しかしIDCなどが今回の件で最も懸念しているのは、攻撃が開始されるまでのスピードです。
IDCのリサーチディレクターであるPhilip Harris氏（プロフィール）は、セキュリティ企業Patchstackの報告を引用し、「今回のWordPressの脆弱性は、新たなリスクの現実を象徴する典型例です。攻撃者は脆弱性の公表からわずか数時間で悪用を開始しており、大半の企業はそのスピードに追いつくだけのパッチ適用ができていません」と述べています。Patchstackの報告では、WordPressがパッチを公開した直後から攻撃者がこの脆弱性を利用していたとされています。
Patchstackは次のように述べています。「この記事を最初に公開した時点では、確認できたリクエストはすべて無害なコアファイルに対する偵察行為でした。しかし、もはやそうではありません。攻撃者は現在pearcmd.phpを利用し、これを使ってPHPファイルをディスクに書き込んでいます。またこのCVEを標的とした公開スキャンツールも出回っています」
IDCのHarris氏は、Patchstackのテレメトリデータがこの新たな現実を如実に示していると指摘します。パッチ公開からわずか5時間で攻撃者の偵察活動が始まり、約1日以内に本格的な悪用が確認されたといいます。「開示から悪用までの間隔はもはや崩壊しており、重大な脆弱性の平均悪用時間がマイナスになるケースすら出てきています。つまり、パッチが公開される前、あるいは公開直後にはすでにエクスプロイトコードが存在しているということです」と同氏は述べます。「今回のWordPressの脆弱性もまさにこのパターンをたどっています。Patchstackは、WordPress 7.1.2のリリースから5時間足らずで最初の探索的なトラフィックを記録しており、攻撃者がスキャン段階から実際のペイロード配信へと移行するにつれ、トラフィック量は1日足らずでおよそ10倍に増加しました」
ニューヨークを拠点とする技術コンサルティング企業Tribeca Softechのチーフストラテジーオフィサーを務めるAman Mahapatra氏（LinkedInプロフィール）も同様の見解を示しています。
「この件で本当に注目すべき数字は、CVSSスコアの9.2ではなく、パッチと悪用の間のギャップです。今回の脆弱性では、そのギャップは事実上ゼロでした」と同氏は述べます。「WordPressは9月22日に7.1.2を公開し、Patchstackは同日11時49分（UTC）には早くも最初の悪用試行をブロックしています。そのペイロードは、パッチが修正しようとしたエンコーディングの問題と完全に一致していました。攻撃者はこの脆弱性を自ら発見したわけではありません。修正内容を読み解いただけなのです。パッチの公開は、いまや実質的にエクスプロイトの手引きを公開しているのと同じことであり、修正までに数週間単位の対応サイクルを続けている企業は、とうの昔に存在しなくなったはずのスケジュール感で動いていることになります」
より迅速なパッチ適用が必要
攻撃者の行動の速さへの対応策の一つとして、アップデートの自動化が挙げられますが、これは必ずしも良い選択肢とは限りません。一部の企業のCISOは、過度なパッチ自動化に慎重な姿勢を示しています。システムへの変更はすべて自らレビューし承認したいと考えており、それは主に2024年のCrowdStrike事件のような大惨事を避けるためです。
Ressl氏はインタビューの中で、自動アップデートに関するもう一つの懸念として、多くの企業がアップデートが正しく実行されたかどうかを十分に検証していない点を挙げています。
「自動アップデートを有効にしていることと、パッチが実際にインストールされたことを検証することは、同じではありません」と同氏は述べます。「互換性や可用性への懸念から、アップデートのテストを行うこと自体は正当な理由です。私が推奨するのは、ステージング環境を含む、影響を受けるすべてのインストール環境に対して、検証を伴う迅速なテスト済みロールアウトを行うことです」
Mahapatra氏は、アップデート自動化に伴う問題は、特に大企業において深刻だと付け加えます。
「WordPressはデフォルトでマイナーセキュリティリリースを自動適用するため、一般的な趣味レベルのブログはおそらくすでにパッチが適用されているでしょう」と同氏は指摘します。「一方、企業サイトでは変更管理を徹底するために自動アップデートを無効化しているのが常であり、結果として最も成熟したガバナンス体制を持つ組織ほど、今週もなお脆弱性にさらされたままである可能性が高いのです。攻撃者がスキャンを続ける中、修正パッチは自社のプロセスによってキューの中で足止めされているからです。認証されていないリモートコード実行の脆弱性と、通常のプラグインアップデートを区別できない変更管理は、企業そのものではなく、プロセス自体を守っているにすぎません。そして今回の脆弱性は、その区別を怠ることの代償がいかに高くつくかを示すものです」
さらにAcceligenceのエグゼクティブアドバイザーを務めるNidhi Luthra氏（プロフィール）は次のように指摘しています。「セキュリティリリースは公開されるとほぼ即座に攻撃者にとっての攻略ロードマップと化す可能性があります。そのため、インターネットに公開されているシステムに対する緊急パッチ適用には、数時間単位での対応が求められます」
見落とされたWordPressサイトが未パッチのままである可能性
Mahapatra氏は、もう一つの、おそらくさらに大きな懸念として、多くの企業のWordPress導入がレーダーの外で行われている実態を挙げます。これらは典型的なシャドーITとは異なり、導入当時は正式に承認されたものではあるものの、IT管理部門にとってはいまだに把握されていないケースが多いのです。
企業においては、と同氏は続けます。「実際の露出範囲は、ほとんどの組織が想定しているよりもはるかに大きいものです。というのも、大半の企業は自社をWordPress事業者だとは考えていませんが、実際にはほぼすべての企業がそうだからです。リスクが潜んでいるのは、ITが一度も棚卸ししたことのないウェブ資産――マーケティング用のマイクロサイト、キャンペーンのランディングページ、地域ごとの国別サイト、外部代理店が構築した投資家向け情報ページ、そして3年前に買収したもののまだ移行が済んでいない企業のサイトなどです。今回影響を受ける[WordPressバージョン]の範囲は4.7.0から7.1.1までと、およそ10年分に及ぶインストールをカバーしています。そして見落とされたサイトこそが、まさにいまだに古いブランチのまま残っているサイトなのです」
Mahapatra氏によれば、この傾向は特に金融業界の企業で顕著に見られるといいます。
「銀行のCISOたちと一緒に外部攻撃対象領域のレビューを行う際、表面化してくるWordPressインスタンスは、企業の公式サイトであることはほとんどありません」と同氏は述べます。「それらはマーケティング部門や子会社、あるいは契約が切れた代理店に属するサイトであることが多く、いずれもセキュリティチームがパッチ適用の対象として管理しているCMDBには載っていないのです」
