CISA、悪用が確認されたWordPress Coreアップグレードの脆弱性を警告

WordPress Coreの一部のアップグレード中に生じる短い時間帯を突かれると、攻撃者がログインなしでウェブサイトのサーバー上でコードを実行できる恐れがあります。

カナダ・サイバーセキュリティセンターによると、CISAは11月3日、CVE-2026-119977を悪用が確認された脆弱性(KEV)カタログに追加しました。この脆弱性は、WordPress 4.7から7.1.3までの各ブランチのうち、未パッチのリリースに影響します。対応する修正がバックポートされた旧ブランチは、この脆弱性から保護されています。 

管理者は安全にアップデートを完了させるとともに、保護が有効になる前に攻撃者がサイトにアクセスしていないかを確認する必要があります。

アップグレード中の時間帯がWordPressサイトを危険にさらす仕組み

深刻度が高いこの脆弱性(CVSS 8.1)は、フルパッケージ版のCoreアップグレード中に作成される、予測可能でウェブからアクセスできる一時ディレクトリのパスに関するものです。攻撃者がタイミングよく一時的なインストーラーファイルに到達できれば、サーバー上でコードを実行できる可能性があります。Wordfenceによると、ラボでのテストでは、この時間帯は通常わずか数秒でした。しかし攻撃者は、この隙を捉えるためにパスへ繰り返しアクセスしていました。 

Cobaltのオフェンシブセキュリティ研究・コミュニティ担当ディレクターであるJoe Brinkley氏は、次のように述べています。「注目すべきは、この脆弱性がアップグレードの過程そのものに潜んでいる点です。システムをより安全にするために各チームが頼りにしているメンテナンス期間中に、リスクが生じてしまいます」

この脆弱性は、 WordPressサイトを認証なしのコード実行の危険にさらしたBricksforgeプラグインの脆弱性とは別のものです。プラグインを更新してもCoreは修正されません。また、Coreを更新しても、脆弱なコンポーネントがすべて解消されるわけではありません。

修正を含むWordPressのバージョンは?

WordPressは10月28日にバージョン7.1.4をリリースし、直ちに更新するよう推奨しています。プロジェクトは、このアップグレードの脆弱性を報告したUmut Bayram氏の功績を認めています。

修正は旧ブランチにも提供されました。 Wordfenceは修正済みのリリースとして、7.0.8、6.9.11、6.8.12、4.7.39などを挙げています。管理者は、7.1.4未満のリリースがすべて脆弱なままだと決めつけず、自分が使うブランチの修正バージョンを確認してください。WordPressは、サポート対象は最新バージョンのみだとしています。

CISAが実環境での悪用を確認している以上、各組織はこの修正を優先して適用すべきです。

インシデント対応を終える前に管理者が行うべきこと

まず、WordPressの各インストール、そのCoreバージョン、更新の責任者(担当者または事業者)を洗い出します。自動更新が実際に完了したかどうかも確認してください。

危険はアップグレード中に生じるため、可能な範囲で、一時的なアップグレード用ディレクトリへの外部からのアクセスを制限するよう、サーバーやホスティングの担当チームに依頼します。この保護策は、セキュリティ修正を遅らせないよう、更新作業と調整しながら進めてください。

依存関係も対象から外さないことが重要です。別件の WordPressのHEIC画像処理を狙った攻撃は、CMSを更新するだけではホスティング環境全体の安全を確保できないことを示しています。

Picus Securityのセキュリティ研究者であるBayram氏は、防御側は露出状況が変わった時点で防御策をテストすべきだと述べています。

「だからこそ、検証を次の定期テストまで待つことはもうできません。何かが変わった時点で始めるべきです」と同氏は語りました。

調査の手順としては、最近のアップグレードの日時と、wp-content/upgrade配下に置かれたインストーラーファイル(特にsetup-config.php)へのリクエストを記録したウェブログを突き合わせます。見覚えのない管理者アカウント、予期しないPHPファイル、設定の変更、通常とは異なる外部への通信も調べてください。これらはあくまで調査の手がかりです。不審なリクエストが1件あるだけでは、侵害されたことの証明にはなりません。

侵入の形跡がある場合は、不審なファイルを削除する前にログを保全し、インシデント対応の担当者を関与させてください。攻撃者がアプリケーションの認証情報やシークレットにアクセスできた可能性を評価し、それらを交換する必要があるかどうかも判断します。

パッチ管理と脆弱性管理の違いは、ここで重要になります。更新に成功すれば脆弱な挙動は塞がれますが、攻撃者のアクセスが排除されたことの証明にはなりません。対応を終える前に、適用した修正、調査で判明した事実、入手できた証拠の不足点を記録してください。マネージドホスティングの利用者は、これらの詳細を事業者に求めるとよいでしょう。

関連記事: Black OctoberのPHPパッチ後にセキュリティチームが確認すべきこと。以前の攻撃の試み、設定上のリスク、公開アプリケーション全体で修正が有効になっているかどうかも解説しています。