WordPressコアの一部のアップグレード中に生じる短い隙を突くと、攻撃者はログインせずにWebサイトのサーバー上でコードを実行できる。
CISAは11月3日、CVE-2026-119977を既知の悪用脆弱性カタログに追加したと Canadian Centre for Cyber Securityによると。今回の脆弱性は、4.7から7.1.3までのWordPress各ブランチにおける未修正のリリースに影響する。対応するバックポート修正が適用された旧ブランチは、この脆弱性から保護される。
管理者は安全にアップデートを完了するとともに、保護が有効になる前に攻撃者がサイトへアクセスしていないか確認する必要がある。
アップグレード中の隙がWordPressサイトを危険にさらす仕組み
CVSS 8.1の高深刻度の脆弱性は、パッケージ全体のコアアップグレード中に作成される、予測可能でWebからアクセス可能なステージングパスに存在する。攻撃者が適切なタイミングで一時的なインストーラーファイルに到達すると、サーバー上でコードを実行できる。Wordfenceによると、ラボ環境でのテストでは通常、隙は数秒しか続かなかったが、攻撃者はその隙を捉えるためパスを繰り返しポーリングしていた。
「この脆弱性が存在する場所は注目に値します。アップグレードプロセスの内部にあるため、チームがサイトの安全性を高めるために頼っている同じメンテナンス期間中に、露出が発生するのです」と、Cobaltの攻撃セキュリティ研究・コミュニティ担当ディレクター、Joe Brinkley氏は述べた。
この脆弱性は、 認証なしのコード実行によりWordPressサイトをさらしたBricksforgeプラグインの脆弱性とは別のものだ。プラグインをアップデートしてもコアは修正されず、コアをアップデートしても脆弱なコンポーネントがすべて解決するわけではない。
修正を含むWordPressのバージョンはどれか？
WordPress 7.1.4は10月28日にリリースされ、直ちにアップデートするよう推奨されている。プロジェクトは、Umut Bayram氏によるアップグレード脆弱性の報告を功績として挙げている。
旧ブランチにも修正が提供されている。 Wordfenceが挙げる修正済みリリースには、7.0.8、6.9.11、6.8.12、4.7.39などがある。管理者は、7.1.4未満のすべてのリリースが依然として脆弱だと決めつけず、自分のブランチにおける修正済みバージョンを確認すべきだ。WordPressによると、積極的にサポートされるのは最新バージョンだけだという。
CISAがこの脆弱性を実環境で悪用されていると特定しているため、組織はこの修正を優先すべきだ。
インシデントを終結させる前に管理者がすべきこと？
まず、各WordPressインストール、コアのバージョン、そしてアップデートの責任者または担当プロバイダーを特定する。自動アップデートが実際に完了していることも確認する。
露出はアップグレード中に発生するため、可能であればサーバーまたはホスティングチームに、一時的なアップグレードディレクトリへのパブリックアクセスを制限するよう依頼する。その保護をアップデートプロセスと調整し、セキュリティ修正を遅らせないようにする。
依存関係も調査対象に含める必要がある。別の WordPress HEIC画像処理攻撃は、CMSだけをアップデートしてもホスティングスタックの安全性が確立したことにはならない理由を示している。
Picus Securityのセキュリティ研究者であるBayram氏は、環境の露出状況が変わった際に防御策をテストすべきだと述べた。
「だからこそ、次回の予定テストまで検証を待つことは、もはやできません。何かが変わった時点で始めるべきです」と同氏は述べた。
調査の一環として、最近のアップグレード時刻と、wp-content/upgrade配下のステージングされたインストーラーファイル、特にsetup-config.phpへのリクエストに関するWebログを照合する。見慣れない管理者アカウント、予期しないPHPファイル、設定変更、通常とは異なる外部接続を調査する。これらは調査の手がかりであり、不審なリクエストだけで侵害が証明されるわけではない。
侵入を示す証拠がある場合は、不審なファイルを削除する前にログを保全し、インシデント対応担当者を関与させる。攻撃者がアプリケーションの認証情報や秘密情報にアクセスできた可能性があるか、それらを交換する必要があるかを評価する。
ここで重要なのは、 パッチ管理と脆弱性管理の違いだ。アップデートが成功すれば脆弱な挙動は解消されるが、攻撃者のアクセスが排除されたことの証明にはならない。対応を終結させる前に、インストールした修正、調査結果、利用可能な証拠の不足点を記録する。マネージドホスティングの顧客は、こうした詳細をプロバイダーに求めるべきだ。
続きを読む： Black OctoberのPHPパッチ後にセキュリティチームが確認すべき事項。以前の攻撃の試み、設定上のリスク、露出したアプリケーション全体で修正が有効になっているかどうかも含む。