WordPress 7.1.4で修正された脆弱性に、パッチ公開直後から攻撃試行が大量発生している

OVERVIEW

2026年10月28日に公開された WordPress 7.1.4 は、本体の更新が走っているあいだだけ、ログインしていない人に遠隔からプログラムを実行されるおそれがあった脆弱性を直しています。セキュリティ企業の Wordfence は、この脆弱性を狙う要求を公開の直後から観測し、最初の21時間で18,500件を超えたと報告しました。

報告が数えているのは試行で、侵入に成功した件数は示されていません。Wordfence の無料版には、この要求を止めるルールが11月27日まで届きません。

ここでは、WordPress 7.1.4 で直ったこの脆弱性について、Wordfence が何を観測したのか、要求がなぜ同じサイトへ繰り返し届くのか、無料のファイアウォールで足りるのかを、Wordfence、Patchstack、WordPress.org の公開情報に沿って書きます。

WordPress 7.1.4の公開直後から、更新中の脆弱性を狙う要求が届いている

Wordfence は2026年10月28日20時30分（協定世界時。日本時間では10月29日5時30分）に、この脆弱性を狙う要求を止めるファイアウォールのルールを出しました。WordPress.org がセキュリティリリースを告知してから、およそ3時間後です。ルールに当てはまる最初の要求は、その9分後に届いています。

最初の21時間に記録した要求は18,500件を超え、どれも更新中に一時的に置かれるインストーラーの場所を狙ったものでした。送信元のうち大きな2つは、少数のサイトへ約14.5時間にわたって要求を繰り返し、ほかの送信元は、一時的な展開先のフォルダ名やバージョンの名前を何通りも変えて試しています。

すべての要求が脆弱な場所を正確に突いていたわけではありません。それでも Wordfence は、長時間の繰り返しと、展開先の形をそのままなぞった要求があったことから、攻撃者はこの脆弱性の仕組みをすぐに理解して狙い始めたと書いています。

Wordfence の評価は CVSS 8.1（High）です。影響を受けるのは WordPress 4.7 から 7.1.3 までで、修正は WordPress 7.1.4 のほか、7.0.8、6.9.11 など、4.7.39 までの各系統に出ています。WordPress 4.6 以前には修正バージョンが出ていません。

狙われているのは、本体の更新でWordPress一式が置かれている数秒間

この脆弱性があるのは、WordPress 本体を更新する処理の途中です。Wordfence によると、完全なパッケージを使って本体を更新するとき、影響を受けるバージョンは新しいファイルを wp-content/upgrade/ の下の、名前が予測できるフォルダへ展開します。この一時的なコピーにはインストーラーも含まれていて、多くのサーバーではこの場所が Web から見えています。

展開されているその瞬間にインストーラーへ要求を当てられると、ログインしていない人でもサーバー上でプログラムを実行するところまで進めてしまう、というのが今回の弱点です。

ただし、成り立たせる条件は厳しいものです。Wordfence は、完全なパッケージでの更新であること、展開先に Web から届いて PHP が動くこと、フォルダの場所が予測できるか見つけられること、WordPress が一時ファイルを片付ける前に終えられることを挙げ、攻撃の難しさを高いと評価しています。研究環境では、展開先が残っていたのは通常数秒でした。

1回の要求で当たる見込みは小さい一方で、自動で要求を繰り返せば当たる確率は上がる、と Wordfence は書いています。同じサイトへ何時間も要求が届いているのは、更新が走る数秒を捕まえるためだというのが Wordfence の見立てです。Patchstack も、修正前のバージョンではこの時間が、自動更新を含めて更新のたびにやってくると書いています。

Patchstack によると、WordPress 7.1.4 は展開先のフォルダ名に16文字のランダムな文字列を付け、フォルダの一覧表示を防ぐ index.php を消さずに作り直すようにしました。本体の更新で作業フォルダの wp-config.php（データベースの接続情報を書く設定ファイル）を本体側へコピーしない変更も入っています。

18,500件は試行の数で、侵入に成功したサイトの数ではない

Wordfence の報告が数えているのは、Wordfence のファイアウォールが記録した要求の件数です。何サイトが実際に侵入されたのか、侵入されたサイトがあったのかは、報告に書かれていません。この報告を引いた10月30日のニュース記事も、成功した件数は報告から分からないと断っています。

日本語のエノルの解説にある「実際の悪用は確認されていません」は、Wordfence の21時間分の集計がそろう前の10月29日6時14分に確認された情報で、成功した侵入が確かめられていない点では食い違っていません。

無料版のWordfenceにこのルールが届くのは、11月27日になる

Wordfence の有料版（Premium、Care、Response）には、10月28日のうちにこのルールが入りました。無料版は通常どおり30日遅れで、届くのは2026年11月27日です。WordPress.org の Wordfence のページも、無料版のファイアウォールのルールは30日遅れで届くと書いています。

ルールが届いていても、設定によっては止められません。この要求は、WordPress を読み込まずに、展開された PHP ファイルへ直接届くからです。Wordfence は、PHP ファイルが動く前にファイアウォールを動かす「Extended Protection」という状態に最適化しておくよう求めています。Patchstack は、WordPress のプラグインとして動くファイアウォールはこの要求では動かないとして、Web サーバーの設定で wp-content/upgrade/ へのアクセスを拒否し、一覧表示されないことを確かめるよう勧めています。

どちらも、ファイアウォールを本体の更新の代わりにはしていません。Wordfence は、ファイアウォールは更新するまでの危険を減らすもので、脆弱な動きそのものを取り除くのは修正バージョンの WordPress 本体だと書いています。

WordPress 7.1.4になったかは、管理画面の「更新」で確かめる

WordPress.org の告知によると、自動バックグラウンド更新が有効なサイトでは WordPress 7.1.4 への更新が自動で始まります。Wordfence も多くのサイトには自動更新で届くとしながら、更新が終わったと決めつけずに、管理画面の「ダッシュボード」→「更新」でバージョンを確かめるよう強く勧めています。

7.1 系なら WordPress 7.1.4、古い系統に留めているなら、その系統の修正バージョン（WordPress 7.0.8、6.9.11、6.8.12 など）になっているかを見ます。WordPress 4.6 以前には修正バージョンが出ないので、サポートされているバージョンへ上げる計画が別に要ります。

サーバーの PHP を新しくしても、WordPress 本体のバージョンは変わりません。PHP そのものの脆弱性は、PHP の脆弱性の記事で別に書いています。

修正前のまま止まっていたサイトは、バージョンのほかに痕跡も見ておく

修正前のバージョンのまま更新が止まっていたサイトについて、Wordfence は本体を修正バージョンにするだけでなく、更新用のフォルダのまわりに不審な動きがなかったかも見直すよう求めており、次のものを挙げています。

wp-content/upgrade/ の下にある PHP ファイルへの、見覚えのない要求
覚えのない管理者アカウント
入れた覚えのないプラグインや、置いた覚えのない PHP ファイル

どのサイトでも、本体を更新したあとは、公開ページの表示、管理画面へのログイン、お問い合わせフォームの送信を一度見ておくと、更新で動かなくなったものがないかが分かります。

参考にした一次情報

本体の自動更新は、始まっても最後まで終わったとは限りません。Wordfence の無料版にも、この脆弱性向けのルールは11月27日まで届きません。誰かが更新の画面でバージョンを見ないと、修正前のまま残っていても気づけません。

サイト番では、プラグインやテーマの定期更新、バックアップ、表示の確認、障害のときの復旧を、担当者が内容を見て行います。

WordPress更新などの保守管理に手が回らない場合は、是非サイト番にお任せください。