2026年9月22日、建国記念日の休日の前日に、WordPress は CVE-2026-87902 を修正するセキュリティアップデート 7.1.2 をリリースしました。この脆弱性はプラグインやテーマではなく、WordPress のコアにあり、4.7.0 から 7.1.1 までのすべてのバージョンに影響します。同日 UTC 11:49（リヤド時間午後 2:49）、セキュリティ企業 Patchstack は最初の悪用の試みを確認し、それから四時間足らずで、サイトのサーバーにファイルを書き込もうとする最初の試みを確認しました。

攻撃は五日間でどう広がったか

その後、攻撃は広がりました。本日9月28日に公開された CrowdSec のレポートによると、同社のネットワークは9月23日から27日にかけて、30,813 の異なる IP アドレスから、この脆弱性に一致する 322,680 件の攻撃シグナルを記録し、9月27日には 124,154 件でピークに達しました。サウジアラビア国家サイバーセキュリティ庁（NCA）は9月23日に「重大」レベルの警報（第 2026-7873 号）を発出し、米国の CISA は9月25日にこの脆弱性を既知の悪用された脆弱性カタログに追加しました。

この脆弱性は何をするのか、平易に言うと

訪問者がページを要求すると、WordPress はそれを表示するためにテーマのどのテンプレートファイルを使うかを決めます。バグはその段階にあります。ログインしていない攻撃者が、その処理をテーマフォルダの外にあるサーバー上の PHP ファイルに向けることができ、WordPress はそのファイルを実行してしまうのです。WordPress はこの脆弱性を 10 点満点中 9.2 と評価し、CISA は 8.1 と評価しています。

WordPress のアドバイザリと研究者のレポートで挙げられた条件がそろうと、これはサイトの乗っ取りにつながります。

  • テーマ：有効なテーマに、名前が page- で始まるフォルダがあること。アドバイザリは、該当するテーマとして Twenty Twelve、Twenty Fourteen、Neve、Hestia、Sydney を挙げています。
  • PHP の設定：register_argc_argv がオンになっていること。CrowdSec によると、これは公式の PHP Docker イメージや、8.5 より古い PHP を動かす cPanel サーバーでのデフォルト設定です。
  • 補助ファイル：PEAR の pearcmd.php がサーバー上にあること。攻撃者はこれを使って新しい PHP ファイル、つまり更新後も残るバックドアを書き込みます。

つまり、この脆弱性はすべてのサイトに同じように影響するわけではありませんが、Security Affairs は次のようにまとめています。コード実行にはサーバーの設定が条件に合うことが必要で、合ってしまうサーバーは多い、と。経営者は通常、どのテーマが有効か、サーバーがどう設定されているかを知りません。したがって、そうでないと証明されるまではサイトが危険にさらされていると考えるのが安全です。

なぜ攻撃は数週間ではなく数時間で来たのか

セキュリティアップデートは、その性質上バグの場所を明らかにします。コードの変更が公開されるからです。Patchstack によると、最初のペイロードは修正によって塞がれたパターンと完全に一致しており、それを書いた者が独自の発見ではなく、修正そのものを手がかりにしたことを意味します。最初の試みは、サイトがどう応答するかを見るために wp-login.php や wp-cron.php といった通常の WordPress コアファイルを要求し、その後ファイルの書き込みへと移りました。

このトラフィックには、自動スキャナーや公開された概念実証（PoC）コードの痕跡も見られます。経営者にとってこれは、誰もあなたのサイトを狙い撃ちしているわけではないということです。ツールは到達できるすべての WordPress サイトを総なめにしており、侵害されたサイトとクリーンなサイトの違いは、更新がツールより先に届いたかどうかにあります。

あなたのサイトは自動で更新されますか？

おそらくそうですが、そう決めつけないでください。WordPress にはバージョン 3.7 から自動バックグラウンド更新があり、5.6 以降は新規インストールでマイナーリリースとメジャーリリースの両方が自動更新されます。7.1.2 の発表では、自動バックグラウンド更新に対応しているサイトは自動的に更新を開始するとしています。

しかし、自動更新は wp-config.php の一行で無効にできます。更新によってカスタマイズしたテーマが壊れないよう意図的に無効にする開発者もいれば、自社側で更新を管理するホスティング会社もあります。何年も前にフリーランサーが作り、契約がすでに終わっているサイトは、誰にも気づかれないまま古いバージョンにとどまっているかもしれません。確認方法は次のとおりです。

  • サイトの管理画面にログインし、「ダッシュボード」メニューの下にある「更新」ページを開くと、そこに現在のバージョンが表示されます。
  • 安全なバージョンは 7.1.2 以降です。サイトが古いブランチにある場合、修正は 4.7 までのすべてのブランチに届いており、7.0.6、6.9.9、6.8.10、4.7.37 も含まれます。完全なリストは、出典にリンクした WordPress のアドバイザリにあります。
  • WordPress によれば、積極的にサポートされているのは最新バージョンだけである点に注意してください。古いブランチに残されたサイトも今回の修正は受け取りましたが、いわば猶予期間を生きている状態です。新バージョンが企業サイトにもたらすものについては WordPress 7.1：主な新機能 で解説しました。

Elementor も：リンク一つで十分

同じ週、人気の WordPress 用ページビルダー Elementor は、バージョン 4.3.0 と 4.3.1 のみに存在する脆弱性を修正しました。サイト管理者がログインしたまま細工されたリンクを開くと、攻撃者は自分が管理する管理者アカウントを作成でき、そのリンクはメール、チャット、コメント経由で届く可能性があります。BleepingComputer によると、これらのバージョンは最大 200万 のサイトで動いています。修正は9月24日に 4.3.2 で提供され、同サイトは記事公開時点で実際の悪用は報告していませんでした。

Elementor が 4.3.2 以降になっていることを確認し、次のことをチームのルールにしてください。サイトの管理画面にログインしている間は、メッセージやコメントのリンクを開かないことです。

9月22日以降、サイトが更新されていない場合

  • 今すぐ更新する：開発者が更新で何かが壊れることを心配しているなら、Patchstack によれば、pagename パラメータでのディレクトリトラバーサルの試みをブロックするか、register_argc_argv をオフにすることで、経路を一時的に塞ぐことができます。これはホスティング会社か開発者の作業であり、更新の代わりにはなりません。
  • サイトが探られたと想定する：開発者かホスティング会社に、誰も追加していない PHP ファイルを探すよう依頼してください。特に /tmp と /var/tmp が対象で、Patchstack は poc87902.php や wp-pear-rce-flag.php といったファイルをコード実行成功の兆候として挙げています。
  • 何か見つかった場合：更新ではなくインシデントとして扱ってください。管理者アカウント、データベース、ホスティングのパスワードを変更し、クリーンなバックアップからサイトを復元してから更新します。
  • サイトが顧客データを保持している場合：注文、問い合わせフォーム、アカウントを保存しているなら、サウジデータ・人工知能庁（SDAIA）の個人データ侵害インシデントに関するガイドにより、管理者は、データまたはその持ち主である人々に害を及ぼしうる侵害を認識してから 72 時間以内に所管当局へ通知する必要があります。

Origami の見解

多くの企業サイトは WordPress で構築された後、印刷されたパンフレットのように扱われています。開発者が納品し、オーナーが支払い、誰が更新を続けるのかは誰も尋ねません。今回の脆弱性は、ウェブサイトがインターネットに公開されたサーバー上で動く生きたシステムであること、そして修正の公開から攻撃者の到来までの間隔が今や時間単位で測られることを思い出させます。本当の問題は WordPress が安全かどうかではありません。WordPress はバグを修正し、4.7 までのすべてのブランチに修正を配布したのですから。問題は、あなたの会社で誰がそれをインストールする責任を負っているかです。

だからこそ私たちは、ウェブサイトの保守契約で、重大なセキュリティアップデートを適用するまでの最大期限を定め、本番サイトの前に更新をテストするステージング環境のコピーを義務づけ、サーバー自体とは別の場所に保管する定期バックアップを確保すべきだと考えています。そして、テーマが更新のたびに壊れるようなカスタマイズをされているせいで更新が先延ばしされ続けているなら、それは WordPress ではなくサイトの作り方の問題であり、次の脆弱性が来る前に直す価値があります。

結論：三つのステップ

  • 今日：管理画面を開き、バージョンが 7.1.2 またはご利用のブランチの修正版であること、そして Elementor が 4.3.2 以降であることを確認する。
  • 今週：開発者かホスティング会社に、見覚えのない PHP ファイルがないかサーバーをスキャンし、自動更新がオンになっていることを書面で確認するよう依頼する。
  • 今月：保守契約にセキュリティアップデートを適用するまでの最大期限を加え、その責任者を指名する。

出典