WordPress 脆弱性の悪用を確認｜更新中の数秒を狙う攻撃と対策

何が起きたのか？

WordPress は2026年10月28日、22件の脆弱性を修正したセキュリティリリース 7.1.4 を公開し、すぐに更新するよう呼びかけました^[1][2]。最も深刻なのが、本体の更新処理中にログインなしでコードを実行されるおそれがある CVE-2026-119977 です^[4]。修正公開から数時間で攻撃の試行が観測され、11月3日には米CISA が KEV に追加しました^[4][5]。

1. 10月28日

   WordPress 7.1.4 を公開

   22件の脆弱性を修正。修正は 4.7 系までの旧系列にも提供^[1][2]。

2. 10月28日 20:30（UTC）

   Wordfence が遮断ルールを配布

   WordPress の発表から約3時間後。最初の攻撃リクエストを検知したのは配布の9分後^[4]。

3. 10月29日

   WordPress がアドバイザリを公開、Wordfence が攻撃状況を報告

   WordPress 自身は深刻度を「low」と評価^[3]。Wordfence はルール配布後の21時間で、インストーラのパスを狙うリクエストを18,500件超記録^[4]。

4. 10月31日

   CVE が NVD に登録

   影響範囲は 4.7〜7.1.3、CVSS 8.1（Wordfence の評価）^[6]。

5. 11月3日

   米CISA が KEV に追加

   米連邦機関の対応期限は3日後の11月6日^[5]。

6. 11月27日（予定）

   Wordfence 無料版に遮断ルールが届く

   有料版より30日遅れの配布^[4]。

KEV は、米CISA が「実際に悪用が確認された」と判断した脆弱性だけを載せる一覧です^[5]。WordPress 本体の脆弱性が KEV に載るのは2026年に入って3回目で、7月21日に2件、9月25日に1件が追加されています^[5]。7月の件では、WordPress 自身が深刻度を理由に、影響を受けるサイトへ自動更新の仕組みで修正を強制配布しました（自動更新を止めているサイトには届きません）^[11]。

なぜ「更新している最中」が危ないのか？

WordPress は本体を更新するとき、新しい版を丸ごと一時フォルダに展開してから所定の場所へ移します。7.1.3 以前はこの一時フォルダの名前が推測でき、多くのサーバーでは Web から見える場所にありました^[3][4]。展開された中には WordPress の初期設定画面（インストーラ）も含まれるため、その数秒の間にインストーラを呼び出されると、コードを実行されるおそれがあります^[4]。

このように「確認した時点」と「使う時点」のずれを突く不具合は、TOCTOU（Time-of-check Time-of-use）と呼ばれます。NVD に登録された情報でも、この脆弱性は TOCTOU の競合状態（CWE-367）に分類されています（分類は CVE を採番した Wordfence による）^[6]。攻撃者は、更新が始まるタイミングを知っている必要はありません。Wordfence によれば、一度きりのリクエストで成功する見込みは低いものの、自動で何度も問い合わせ続ければ成功の確率は上がります^[4]。

Wordfence は、成功には次の4つの条件がそろう必要があるとしています^[4]。攻撃の難しさを反映して CVSS は 8.1 で、「攻撃の複雑さ：高」と評価されています^[6]。一方、WordPress 自身はアドバイザリで深刻度を「low」としており、評価は分かれています^[3]。

1. インストーラを含む完全パッケージで本体を更新していること^[4]
2. 一時フォルダが Web から見え、その中の PHP が実行できること^[4]
3. 一時フォルダの場所が推測できるか、見つけられること^[4]
4. WordPress が一時ファイルを片付ける前に、攻撃を完了できること^[4]

評価が「低い」ことは、放置してよい理由にはなりません。Wordfence は、大口の送信元2つが少数のサイトに約14.5時間にわたって繰り返し問い合わせを続けていたと報告しており、この動きは更新のすき間を捕まえようとする行動と一致するとしています^[4]。攻撃者はすでに条件を理解したうえで、待ち構える手口をとっています。

なお、Wordfence が報告しているのは攻撃の試行で、侵害が成立した件数は示していません^[4]。CISA の KEV でも、ランサムウェアでの利用は「不明」とされています^[5]。

日本語版の WordPress では何が違うのか？

日本語版のサイトを管理画面から日本語版のまま手動で更新すると、毎回インストーラを含む完全パッケージが使われます。編集部が11月4日に WordPress の更新 API を日本語の設定で照会したところ、日本語版として提示される更新は完全パッケージだけで、差分だけを入れる部分パッケージはありませんでした^[7]。つまり、日本語版のままの手動更新では、この脆弱性の1つ目の条件が必ずそろいます。なお、同じ更新画面に表示される英語版（en_US）での更新を選ぶと、部分パッケージが使われます^[7][14]。

自動バックグラウンド更新では、日本語のサイトでも、言語に依存しない差分だけの部分パッケージ（更新 API 上は en_US 扱い）が選ばれ、こちらにはインストーラが含まれていませんでした^[7][15]。自動更新は、可能な限り部分パッケージを使う設定で動きます^[15]。一方、修正版を当てる更新そのものも、更新前に入っている古いコードが展開を行います^[14]。脆弱な版から 7.1.4 へ完全パッケージで上げる場合は、その最後の1回も危険な時間を含むということです。

upgrade フォルダに置いた .htaccess では防げないのか？

防げません。7.1.3 以前の更新処理は、展開を始める前に upgrade フォルダの中身を、隠しファイルも含めてすべて削除します^[8]。修正版の 7.1.4 も、残すのは index.php だけです^[9]。この削除は本体だけでなく、プラグインやテーマの更新でも同じ処理を通ります^[8]。upgrade フォルダの中に置いた .htaccess は、ファイルの権限で削除できない場合などを除き、更新が始まった時点で消えます。

upgrade フォルダ自体に .htaccess を置いてアクセスを拒否するのは、一見もっともらしい対策です。しかしソースコードを読む限り、守りたい「更新中」にはその設定はもう残っていません^[8][9]。遮断ルールは upgrade フォルダの外、つまりサイト直下や wp-content フォルダの .htaccess、または Web サーバーの設定ファイルに置く必要があります。

• Apache（多くのレンタルサーバー）：サイト直下の .htaccess の # BEGIN WordPress より上に RedirectMatch 403 ^/wp-content/upgrade/ を置く（wp-content フォルダに別の .htaccess があっても効きやすい書き方）
• nginx：サーバー設定に location ^~ /wp-content/upgrade/ { deny all; } を加える
• WordPress をサブディレクトリに置いている場合は、パスをその構成に合わせる
• 設定後、存在しない /wp-content/upgrade/test.php をブラウザで開き、404 ではなく 403 が返ることを確かめる（フォルダの URL だけだと、一覧表示の禁止でも 403 になり、効いていると誤認しやすい）

upgrade フォルダは、更新のときにサーバー内部でファイルを展開する作業場所です。訪問者に配信する必要のあるファイルは置かれないため、Web からのアクセスを拒否しても、通常はサイトの表示に影響しないと考えられます。ただし、構成によっては影響が出る可能性もあるため、本番に入れる前に、検証環境やバックアップを用意したうえで試してください。

どのバージョンが影響を受け、どこまで直っているのか？

影響を受けるのは 4.7〜7.1.3 で、修正は最新の 7.1.4 に加え、4.7 系までの各系列に提供されています^[4][6]。4.6 以前には修正が提供されず、正式なサポートは最新版だけです^[1][2]。自社サイトの版が下の表の「修正版」以上になっているかを確認してください。

7.1.4 のほかの21件は、多くが寄稿者・投稿者・編集者などログインした利用者を前提とする格納型クロスサイトスクリプティング（XSS）です^[4]。前提条件があるぶん危険度は下がりますが、管理者が悪意あるページを開くと、アカウントの乗っ取りやサイトの改ざんにつながるおそれがあります^[4]。外部の書き手や制作会社に投稿権限を渡しているサイトでは、こちらも早めに修正版を入れる理由になります。

今すぐやることは何か？

最初にやるのは、管理しているすべての WordPress が修正版になっているかを、自分の目で確かめることです。Wordfence も、自動更新が済んだと決めつけず、管理画面の「ダッシュボード」→「更新」で版を確認するよう勧めています^[4]。次に、未修正だった期間があるサイトの点検です。

点検の項目は、Wordfence が未修正だったサイトに勧めている確認内容に沿っています^[4]。不審な管理者アカウントやファイルが見つかった場合は、更新だけでは不十分です。パスワードの変更、不審なファイルの削除、バックアップからの復元を含めて、侵害を前提に対応してください。

自動更新を止めているサイトはどうすべきか？

セキュリティ修正を含むマイナー更新の自動適用は、原則として有効のままにしておくべきです。WordPress は 3.7 から自動バックグラウンド更新を備え、マイナー更新は既定で有効になっています。公式ドキュメントも、無効にすることは強く非推奨としています^[10]。

それでも、過去に表示崩れを恐れて自動更新を止めたサイトは少なくありません。wp-config.php に AUTOMATIC_UPDATER_DISABLED や WP_AUTO_UPDATE_CORE を書くと、自動更新が止まったり範囲が変わったりします^[10]。担当者が替わってこの設定が忘れられると、今回のような修正が届かないまま運用が続きます。

WordPress 本体の脆弱性は、2026年に入って7月・9月・11月と KEV への追加が続いています^[5]。プラグインやテーマの管理に加えて、本体の版を誰がいつ確認するのかを、保守契約や社内の担当表に書いておくことが、次の脆弱性への備えになります。制作会社に保守を任せている場合は、契約に本体の更新と版の報告が含まれているかを確かめてください。

AI を使った制作・運用で気をつけることは？

AI でサイトの改修案や設定ファイルを作るときは、出てきた対策を「そのまま効くか」まで確かめる必要があります。今回の upgrade フォルダの .htaccess のように、もっともらしい対策でも、ソフトウェアの実際の動きと合わず、肝心なときに効かないことがあります^[8]。AI が提案した設定は、出典となる公式ドキュメントやソースコードと照らし合わせ、検証環境で動作を確かめてから本番に入れてください。

また、AI のコーディング支援で WordPress のテーマやプラグインを手早く作るほど、管理する部品は増えます。誰がどのサイトを作り、どの版で動いているかを一覧にしておくことは、AI の時代の脆弱性対応でも基本になります。生成AI を業務で使う際の考え方は、AIセキュリティとはで整理しています。

まとめ

CVE-2026-119977 は、WordPress 本体を完全パッケージで更新している数秒の間に、ログインなしでコードを実行されるおそれがある脆弱性です^[3][4]。2026年10月28日に修正版が公開され、11月3日に米CISA が悪用確認済みとして KEV に追加しました^[1][5]。

日本語版のサイトを管理画面から日本語版のまま手動で更新すると、毎回インストーラを含む完全パッケージが使われます^[7]。upgrade フォルダの中に置いた .htaccess は更新の開始時に消えるため、遮断ルールはその外に置く必要があります^[8][9]。まずは全サイトの版を確認し、未修正だったサイトはログと管理者アカウントを点検してください。PHP の脆弱性への対応はPHP2Shell の解説記事、よくある質問はFAQもあわせてご覧ください。