CVE-2026-119977により、攻撃者はWordPressのコア更新中にサイトを乗っ取れます。CISAは悪用を確認しており、ユーザーにはパッチの適用とアップグレード時の保護対策が呼びかけられています。
米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）は、WordPressコアの脆弱性が攻撃者に悪用されていると警告しました。この脆弱性を突かれると、更新中にWebサイトを乗っ取られるおそれがあります。CVE-2026-119977として追跡されているこの脆弱性は、アップデータによる一時インストールファイルの扱いに起因します。標的サイトのアカウントを持たない攻撃者が、リモートコード実行に至る可能性があります。
StudySecurity
この脆弱性を発見したのは、Picus Securityのセキュリティ研究者Umut Bayram氏です。CVSSスコアは8.1で、11月3日にCISAの「既知の悪用された脆弱性（KEV）カタログ」に追加されました。
公表は最近ですが、Bayram氏は問題の根本的な挙動が2008年にリリースされたWordPress 2.7にまでさかのぼることを突き止めました。公開されているセキュリティ情報では、影響を受けるバージョンは4.7から7.1.3までとされています。一方、同氏の調査では、それより古いリリースも影響を受けるとしています。実際に悪用できるかどうかは、更新パッケージの内容、サーバー設定、そして攻撃者が一時ファイルの場所を特定できるかによって決まります。
更新がWebサイトを危険にさらす仕組み
コア更新の際、WordPressはダウンロードしたファイルをwp-content/upgrade/配下の一時ディレクトリに展開してから、稼働中の環境にコピーします。パッケージにWordPressのインストーラーが含まれ、さらにサーバーがそのディレクトリへのWebアクセスとPHP実行を許可している場合、攻撃者は更新の実行中にWordPressの一時コピーへアクセスできます。
一時インストーラーは、近くの場所に既存の設定ファイルがないか確認しますが、稼働中サイトのwp-config.phpは見つけられません。そのため、展開されたコピーを未設定の新規インストールとみなします。
間に合うタイミングでこのインストーラーに到達できた攻撃者は、自身が管理するデータベースの接続情報を入力できます。するとインストーラーは、一時ディレクトリ内に新しいwp-config.phpを作成します。
脆弱なリリースでは、アップデータが攻撃者の作成したこのファイルを、稼働中サイトの設定ファイルに上書きコピーしてしまうことがあります。これによりWordPressは攻撃者のデータベースに接続されることになり、攻撃者はそこで管理者アカウントを作成できます。管理者によるプラグインのインストールを許可している一般的な単一サイト構成では、サーバー上でPHPコードを実行する経路が開かれることになります。
Bayram氏は、この一連の流れを公開した技術分析で解説しています。攻撃が成立するかどうかは、TOCTOU（time-of-check time-of-use）の競合状態に勝てるかにかかっています。つまり、WordPressが一時インストールを削除する前に、更新の各段階の合間を突いて行動する必要があります。
すべての更新で、必要なファイルが露出するわけではありません。攻撃者は、ステージングディレクトリの場所も特定しなければなりません。古いリリースの一部ではパスにランダム性が加えられており、その場合は名前を知る別の手段がなければ悪用できません。
WordPressが修正版を公開
WordPressは、この脆弱性に対処するため、10月28日にバージョン7.1.4をリリースしました。修正では、一時ディレクトリ名のランダム化、ディレクトリ一覧の表示を防ぐファイルの保持、ステージングされたwp-config.phpが稼働中の設定に上書きコピーされるのを阻止する処理が加えられています。
セキュリティ修正は、4.7までさかのぼる旧ブランチにもバックポートされました。ただしWordPressは、積極的にサポートされるのは最新バージョンのみだと説明しています。2.7から4.6までのリリースにはこの修正が提供されていないため、アップグレードが必要です。
CompareSecurity
CISAは、対象となる連邦政府のシステムについて、11月6日を対処期限に設定しました。また、拘束的運用指令（BOD）26-04に基づき、フォレンジックによる初期調査（トリアージ）も必須としています。ただし、悪用に関する警告では、攻撃者の正体や、侵害されたWebサイトの数は明らかにされていません。
修正版への初回更新にも保護が必要
修正版を適用する際には、追加の予防策が必要です。展開の段階は、Webサイトにすでにインストールされているアップデータを通じて実行されるためです。
パッチ未適用のサイトが修正版リリースに更新される場合、新しいコードは一時的な設定ファイルが稼働中のファイルを置き換えるのを防ぎます。しかし、古い展開コードは、予測可能でWebからアクセスできる場所に一時インストーラーを残してしまう可能性があります。
攻撃者は、WordPressがそれを片付ける前に、この一時インストールを設定してPHPコードを実行できるかもしれません。そこで動くコードは、Webサーバーの権限で実行されます。その権限が稼働中サイトのファイルに対して持つアクセス権も、すべて含まれます。
Bayram氏は、更新を始める前にwp-content/upgrade/へのWebアクセスを拒否し、このディレクトリへのリクエストが403レスポンスを返すことを確認するよう推奨しています。この制限は、サーバー設定またはWordPressルートの.htaccessファイルで適用してください。アップグレードディレクトリ内に置くと、アップデータに削除されるおそれがあります。
別の方法として、管理者は修正版リリースを公開Webディレクトリの外でダウンロード・展開し、wp-config.phpとwp-contentを残したまま、コアファイルを手動で置き換えることもできます。標準のwp core updateコマンドは同じコアアップデータを使うため、この方法の代わりにはなりません。
AIの支援により、調査は約4時間で完了
Bayram氏によると、この脆弱性は研究パートナーとしてGPT-5.6 Solを使って発見したとのことです。アップデータの調査から、動作する攻撃チェーンの完成までに要した時間は約4時間でした。
StudySecurity
Hackread.comに寄せたコメントで同氏は、脆弱性調査が高速化すれば、攻撃者も広く使われているソフトウェアの弱点を見つけやすくなると警告しました。
「キャリアの浅い研究者が午後のうちに20年前のRCEを見つけられるなら、攻撃者にも同じことができます」とBayram氏は述べました。
また、本番環境での更新には時間がかかるため、パッチが公開された後も組織は危険にさらされたままになると指摘しています。
「それまでの間は無防備な期間が生じ、まさにそこで攻撃者が動いています」と同氏は語りました。
Bayram氏は、定期的なテストを待つのではなく、システムに変更があったときに防御策を検証するよう組織に促しました。
「それが合図です。そのときこそ、自分たちが悪用される可能性があるのか、そして防御策が実際にそれを止められるのかを確かめるべきです」
翻訳元: https://hackread.com/cisa-hackers-exploiting-wordpress-core-vulnerability/
