Key Takeaways
- CVE-2026-119977は、WordPressコアのバージョン4.7から7.1.3に存在する、認証不要のリモートコード実行の脆弱性です。WordPress 7.1.4と、4.7系までの各ブランチ向けセキュリティリリースで修正されており、これらはすべて2026年10月28日と29日に公開されました。
- この脆弱性が悪用可能になるのは、サイトの更新中だけです。完全パッケージによるコア更新の際、WordPressはインストーラを含む新しいリリースを、Webサーバ経由でアクセスできる、名前を予測可能なフォルダに展開していました。更新処理によってこのフォルダが削除される前にインストーラへリクエストを送れば、攻撃者はサーバ上でコードを実行できます。
- 攻撃を成功させるタイミングは非常に限られています。WordPressサイト向けの代表的なセキュリティプラグインおよびファイアウォールであるWordfenceの検証では、悪用可能な時間はわずか数秒でした。このため、WordPressは深刻度を「低」と評価している一方、Wordfenceが採番したCVEの登録情報では「高」（CVSS 3.1スコア：8.1）と評価されています。攻撃者は成功確率の低さを試行回数で補っています。Wordfenceでは、ファイアウォールルールの有効化から9分後に最初のリクエストが検出され、最初の21時間で、一時配置されたインストーラのパスに対するリクエストが18,500件以上記録されました。
- 攻撃の試みは続いています。Wordfenceの脆弱性情報では、11月3日までの24時間に13,835件の攻撃をブロックしたとされています。10月30日までの24時間に報告された62,969件からは減少しています。
- 11月3日時点で侵害に成功した事例は報告されておらず、この脆弱性は米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）の「悪用が確認された脆弱性（KEV）」カタログにも登録されていません。
- 7.1.4または使用中のブランチの修正版に更新してください。更新そのものが悪用可能な時間を生むため、Webサーバを管理するチームは、先にwp-content/upgrade/へのWebアクセスをブロックする必要があります。その後、このパス配下のPHPファイルへのリクエストがログにないか確認してください。
経緯
2026年10月28日、WordPressは22件の脆弱性を修正するセキュリティリリースであるバージョン7.1.4を公開しました。大半の脆弱性を悪用するには認証済みのアカウントが必要ですが、特に注目すべきなのは、認証を必要としない、コア更新時の一時配置処理の不備です。翌10月29日にはWordPressのセキュリティアドバイザリが公開され、7.0.8から4.7.39まで、サポート対象の各ブランチの修正版が示されました。この問題はPicus SecurityのUmut Bayram氏が発見し、責任ある開示の手続きに従って報告しました。CVE識別子「CVE-2026-119977」はWordfenceによって採番され、10月31日に公開されました。
攻撃者の動きは、多くのサイト管理者よりも迅速でした。Wordfenceはリリースから約3時間後の10月28日20時30分（UTC）に、有料顧客向けのファイアウォールルールを展開し、その9分後に最初のリクエストを検出しました。最初の21時間で、一時配置されたインストーラ「setup-config.php」のパスへのリクエストが18,500件以上記録されています。リクエスト数が最も多かった上位2つの送信元は、それぞれ少数のサイト群に対して約14.5時間にわたり繰り返しアクセスし、更新によって悪用可能になる瞬間を待ち続けていました。ほかの送信元は、一時配置フォルダ名やバージョン名をさまざまに変えて試していました。すべてのリクエストが実際に脆弱なパスを指定していたわけではありませんが、これらの探索から、攻撃者が短時間で競合状態を利用する仕組みを理解したことがわかります。
攻撃件数はピークを過ぎ、現在は減少しています。The Hacker Newsは、10月30日までの24時間にWordfenceが62,969件の攻撃をブロックしたと報じています。一方、Wordfenceの脆弱性情報では、11月3日までの24時間の件数は13,835件でした。これらはWordfenceが保護するサイトだけの集計であり、実際の件数はさらに多いと考えられます。
TrendAI™のテレメトリでも、同様の傾向が見られます。この脆弱性に対応するネットワークおよびサーバ向けのルールを10月30日と31日に提供して以降、顧客環境に対する数千件の悪用の試みが記録されており、その数は現在も増え続けています。ただし、侵害が確認された事例はありません。これまでに調査したエンドポイントのアラートは、すべて正規のWordPressまたはプラグインの更新に伴うものでした。TrendAI™をご利用のお客さまは、ナレッジベースの記事で、利用可能なソリューションと、この脆弱性を緩和する方法をご確認いただけます。
脆弱性の仕組み
WordPressのコアファイルには、変更されたファイルだけを含む差分パッケージと、リリース全体を含む完全パッケージの2通りの更新方法があります。影響を受けるバージョンでは、完全パッケージを使用すると、新しいリリースがwp-content/upgrade/配下の、名前を予測可能な作業用フォルダに展開されていました。このフォルダはWebルート内にあるため、多くのサーバでは誰でもフォルダ内のファイルへリクエストを送れます。
一時配置されたコピーには、WordPressのインストーラ「wp-admin/setup-config.php」が含まれています。稼働中のサイトでは設定ファイル「wp-config.php」がすでに存在するため、インストーラは実行されません。しかし、一時配置されたコピーには設定ファイルがないため、フォルダが存在する間は、誰がリクエストを送ってもインストーラが実行されます。攻撃者は、この一時配置されたWordPressの接続先を自ら管理するデータベースに設定し、Webサーバのアカウント権限でサーバ上のコードを実行できます。
Wordfenceの説明によると、攻撃が成立するには次の4つの条件がそろう必要があります。
- サイトが完全パッケージによるコア更新を実行すること。
- 一時配置フォルダに外部からアクセスでき、その中でWebサーバがPHPを実行すること。
- 攻撃者がフォルダのパスを把握しているか、推測できること。
- WordPressがフォルダを削除する前に、攻撃者がインストーラへアクセスすること。
Wordfenceによると、WordPress 7.1.4では、一時配置フォルダ名のランダム化、インデックスガードの追加、一時配置された設定データが安全性を確認されないまま本番環境へ反映されることの防止によって、この問題を解消しています。この修正は、影響を受けるすべてのブランチにバックポートされました。
深刻度の評価が分かれる理由
WordPressはこの問題の深刻度を「低」と評価しています。一方、CVEの登録情報では、CVSS 3.1スコアが8.1（AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H）の「高」とされています。どちらの評価にも根拠があります。この攻撃は認証情報を必要とせず、任意のコードを実行できるため、スコアは高くなります。ただし、リクエストが届く瞬間に更新処理が実行されている必要があり、検証では悪用可能な時間はわずか数秒でした。このため、攻撃の複雑さは「高」とされ、WordPressは個々のサイトに対して攻撃が成功する可能性を低く見ています。
ただし、攻撃の規模と自動更新を考慮すると、状況は変わります。大半のWordPressサイトは、バックグラウンドの自動更新でセキュリティリリースを受け取るため、管理者が監視していない間にも、各サイトのスケジュールに従って悪用可能な時間が生じます。攻撃者が特定のサイトの更新時刻を予測することはできなくても、自動化ツールを使えば、数千のサイトに数秒おきにアクセスしながら待ち続けられます。Wordfenceが観測した繰り返しのアクセスは、まさにこの戦略によるものです。1つのサイトに対する成功確率は低くても、インターネット全体で見れば、低いとは言えません。
判明していることと未確認のこと
| 影響を受ける範囲 | WordPressコア4.7.0～7.1.3。完全パッケージによるコア更新中に影響を受けます。 |
|---|---|
| 修正済みバージョン | 7.1.4、7.0.8、6.9.11、および4.7.39までの各ブランチに対応する修正版。4.6以前には修正版がありません。 |
| 深刻度 | CVE登録情報：CVSS 3.1スコア8.1（高）。WordPressの評価：低。 |
| 悪用の状況 | 10月28日以降、大量の悪用の試みが続いています（11月3日までの24時間にWordfenceが13,835件をブロック）。侵害に成功した事例は報告されておらず、TrendAI™のテレメトリでも確認されていません。 |
| CISA KEV | 未登録（11月2日確認）。 |
| 公開攻撃コード | なし。概念実証（PoC）と称するGitHubリポジトリはスキャナであり、この脆弱性を悪用するものではありません（TrendAI™ Researchが10月31日に検証）。 |
| 攻撃者の特定 | 特定されていません。IPアドレスの件数、ユーザエージェント、ペイロードは公開されていません。 |
組織が取るべき対策
- Webサーバを管理している場合は、更新前に一時配置フォルダへのアクセスをブロックします。 更新時に悪用可能になるため、まず/wp-content/upgrade/へのWebリクエストを拒否してください。ルールはサーバ設定、Webアプリケーションファイアウォール、またはCDNに設定し、フォルダ内のファイルには記述しないでください。古いバージョンでは更新中にフォルダの内容が消去されるため、そこに配置したルールも削除されてしまいます。たとえば、nginxではlocation ^~ /wp-content/upgrade/ { deny all; }、ApacheではRedirectMatch 403 ^/wp-content/upgrade/を設定します。すぐに設定できない場合でも、更新を先延ばしにしないでください。7.1.4では、ほかにも21件の脆弱性が修正されています。
- 更新し、バージョンを確認します。 WordPress 7.1.4または使用中のブランチの修正版をインストールしてください。自動更新が実行済みだと思い込まず、集中管理の対象外になっているマーケティング用、地域別、キャンペーン用のサイトも含め、すべてのサイトでバージョンを確認してください。4.6以前には修正版がないため、アップグレードするか、サイトをオフラインにする必要があります。
- 悪用の試みと、その後の痕跡を調べます。 Webサーバのログで、wp-content/upgrade/配下のPHPファイル、特にsetup-config.phpへのリクエストを検索してください。リクエストがあるだけでは攻撃を試みたことを示すにとどまりますが、更新中に200のレスポンスが返っている場合は調査が必要です。wp-content/upgrade/配下に自分たちで配置していないPHPファイルがないか、見覚えのない管理者アカウントや想定外のプラグインがないかも確認してください。
- 攻撃が成功した場合は、侵害として対応します。 更新中にインストーラへのリクエストが成功した場合は、サーバ上でコードが実行されたと考えてください。データベースと管理者の認証情報を変更し、サイトにWebシェルがないか調査してください。
TrendAI™による支援
- エンドポイントとネットワークでの仮想パッチ： TrendAI™の仮想パッチは、ネットワークの通信経路上と、物理サーバおよび仮想サーバを含むエンドポイントで、CVE-2026-119977の悪用の試みを防ぎます。ネットワーク向けには、TrendAI Vision One™ TippingPoint™の保護機能が10月30日に提供され、初期設定で有効かつブロックする設定になっています。エンドポイント向けには、TrendAI Vision One™ Endpoint Securityの保護機能が10月31日に提供され、推奨設定の検索によって必要なサーバに適用されます。初期設定は検出モードのため、更新中の悪用の試みをブロックするには、防御モードに切り替えてください。
- ネットワークの検出と対応： TrendAI Vision One™ Network Securityは、ネットワーク上で脆弱性の悪用を試みるリクエストを検出します。
- 検出と対応： TrendAI Vision One™には、upgradeフォルダ内の列挙や、一時配置されたsetup-config.phpの変更を検出する機能が新たに追加されています。また、Webサーバプロセスによるシェルの起動、ディスクへのWebシェルの書き込み、SSH鍵を利用した永続化など、侵害後のサーバで攻撃者が行う活動に対応する既存の検出機能も90種類以上あります。
- エクスポージャの把握： TrendAI Vision One™ Cyber Risk Exposure Management（CREM）は、脆弱なWordPress環境を特定し、更新の優先順位付けを支援します。
- 脅威ハンティング： TrendAI Vision One™を使用して、Webサーバで上記の検出が発生していないか、また、wp-content/upgrade/配下のPHPファイルへのWebリクエストがないか検索してください。
参考記事：
Racing the Update: Attackers Probe a WordPress Core Flaw That Opens During Patching
翻訳：与那城 務（Platform Marketing, TrendAI™ Research）