あなたのサイトは、もう7.1.4になっていますか。
3週間前に7.1.3が出たばかりなのに、また来ました。
今回は22件です。7.1.3の7件の3倍あります。
しかも、いちばん重い1件は、ログインなしで狙えて、セキュリティプラグインでは防げない種類のものです。
更新のほかに、手を動かして足しておきたいことが1つあります。順番に見ていきます。
22件のうち、ログインなしで狙えるのは2件です。
10月28日、7.1.4が出た
公開は2026年10月28日（現地時間）です。
前回の7.1.3が10月6日なので、ちょうど3週間後になります。
直った脆弱性は22件。ただ、公式の一覧では17項目にまとめて載っています。いくつかの項目が、複数の脆弱性を含んでいるからです。報道によって「17件」と「22件」が混ざっているのは、このためです。どちらも間違いではありません。
同じ日に、サポートしているすべての系統に修正版が出ました。7.0.8、6.9.11、6.8.12、6.7.11、6.6.11、6.5.14、6.4.14と続いて、いちばん古いのは4.7.39です。7.1に上げていないサイトも、自分の系統の修正版で直せます。4.6より前には、修正がありません。
自動更新が有効なら、もう入っているはずです。
この記事を書いている10月30日の時点で、実際の攻撃は報告されていません。CVE番号とCVSSのスコアも、まだ見当たりません。
いちばん重い1件：更新の途中に開く「数秒の窓」
冒頭の1枚目の図が、この件です。
WordPressは、本体を更新するとき、新しい版を wp-content/upgrade/ の中に展開してから入れ替えます。
7.1.3までは、この作業フォルダーの名前が推測できるものでした。しかも片付けの処理で、フォルダーの一覧表示を防ぐための index.php が消されていました。
つまり更新の数秒間、WordPressの丸ごとのコピーが、推測できるURLで、外から見える状態になっていたわけです。
そのコピーの中には、wp-admin/setup-config.php があります。WordPressを最初に入れるときに使う、あの設定画面です。これはサイトの設定がなくても動きます。ここを突けば、リモートからコードを実行できる、という報告でした。報告者はUmut Bayramさんです。
ログインは要りません。
ただ、窓が開くのは数秒だけです。そのタイミングを突く必要があるので、Patchstackは「実際に狙うのは難しい」と評価しています。
難しいのですが、この窓は更新のたびに毎回開きます。夜中に自動更新が走ったときも同じです。
余談ですが、Patchstackによると、この仕組みの根っこはWordPress 2.8の頃からあったそうです。2.8は2009年の版なので、17年近く前からある仕組みということになります。
7.1.4では、作業フォルダーの名前の後ろにランダムな16文字が付くようになりました。index.php も、消さずに作り直します。リリースの告知には書かれていませんが、wp-config.php が作業フォルダーの外にコピーされないようにする変更も入っていると、Patchstackは指摘しています。
そして、ここが大事なところです。
この件は、WordfenceやSiteGuardのようなPHPで動くファイアウォールでは防げません。
展開されたコピーは、そのコピー自身のファイルで動きます。本体のWordPressを通らないので、本体に入っているセキュリティプラグインは関わる場面がありません。
だからPatchstackは、Webサーバーの側で wp-content/upgrade/ へのアクセスを止めるよう勧めています。これは、このあと一緒にやります。
残りの20件あまり：多くは寄稿者以上が前提
2枚目の図に戻ります。
ログインなしで狙えるのは、もう1件あります。カスタマイザーで公開前に変えた内容が、ログインしていない訪問者に見えてしまう件です。テーマの模様替えを途中まで進めて保存していた、というサイトは、その途中の内容が漏れる可能性がありました。
それ以外は、ほとんどが保存型のXSSです。
寄稿者以上のアカウントで細工したブロックを保存しておき、管理者や編集者がそれを開いたときに、管理者のブラウザーでスクリプトが動く。その型が並んでいます。
中でも多いのがInteractivity APIまわりで、6件あります。javascript: で始まるURLを割り当てる、イベントハンドラーを割り当てる、プロトタイプ汚染、object 要素で管理画面を読み込ませる、アップロードしたテキストファイルを経由するRouter（これは投稿者以上）、それにDoS。Interactivity APIは、フロント側の仕組みが6.4、PHP側のクラスが6.5から入っています。
ほかには、ブロックの区切りに空白を入れる手口、カスタマイザーの部分更新、カテゴリーブロック、コメントのページ送りや前後の記事へのリンクのラベル。どれも寄稿者以上が前提です。
編集者以上が必要なのが、個人データ消去リクエストの画面のXSSです。管理者が「ツール」の「個人データの消去」を開いたときに動きます。
少し変わり種が、「メモ」機能の権限の件です。記事を編集する権限がないのに、その記事のメモを読んだり、直したり、消したりできました。ただし、moderate_comments の権限を持たせた独自の権限グループや投稿タイプがある場合に限られます。
ほかに、マルチサイトのユーザー一覧のエスケープ、画像ブロックとプレイリストブロックの preg_replace()、記事の本文がScript Moduleのデータの要素IDを横取りする件が、強化として直っています。
もう一つ、余談です。
今回も報告者の欄にAnthropicの名前があります。個人データ消去の画面のXSSと、マルチサイトのユーザー一覧のエスケープの2件です。7.1.3では7件中3件がAnthropicでした。AIの会社がWordPressのコアの脆弱性を報告する側に並ぶのは、もう珍しい光景ではなくなってきました。
脆弱性ではありませんが、同梱しているルート証明書も入れ替わりました。インドの認証局eMudhraの証明書が失効した件への対応で、4つ追加、5つ削除です。10月21日のNode.jsのセキュリティリリースでも、同じeMudhraの件が入っていました。同じ出来事が、別々のソフトの更新として順に届いているのが見えて、少し面白いところです。
いま確認すること
まず、版の確認です。
管理画面の「ダッシュボード」→「更新」を開いて、7.1.4になっているか見てください。7.1以外の系統なら、上に書いたその系統の修正版になっていれば大丈夫です。WP-CLIが使えるなら、wp core version の1行で確かめられます。
自動更新が効いているはず、と思い込まないのがコツです。マイナー更新を止めるプラグインや、wp-config.php の定数で止めているサイトもあります。保守を任されているサイトがあれば、そちらも1つずつ見ておきましょう。
次に、更新の途中の窓を、Webサーバーの側で閉じておきます。
7.1.4で窓自体はほぼ閉じましたが、念のための二重の鍵です。Xserverのように .htaccess が使えるサーバーなら、サイトのルートにある .htaccess の先頭、# BEGIN WordPress の行より上に、次の1行を足します。
| 1 | RedirectMatch 403 ^/wp-content/upgrade/ |
足したら、ブラウザーで https://（あなたのサイト）/wp-content/upgrade/ を開いてみてください。403（アクセス禁止）が返れば、外からは入れません。
WordPressの更新は、ファイルを直接書き換えて進むので、この1行で更新が止まることはありません。
ひとつ注意があります。wp-content/upgrade/ の中に .htaccess を置く方法は、勧めません。WordPressは更新のたびにこのフォルダーの中身を掃除するので、置いたファイルが消えてしまうことがあるからです。ルートの .htaccess に書くのが確実です。
# BEGIN WordPress と # END WordPress の間には書かないでください。そこはWordPressが書き換えることがあります。
最後に、寄稿者以上のアカウントの顔ぶれです。
今回の多くは、寄稿者以上の権限が入り口になっています。会員登録を開いているサイトや、外部の書き手に寄稿者の権限を渡しているサイトは、一覧を一度見直しておくと安心です。自分ひとりで書いている個人のサイトなら、ここは気にしなくて大丈夫です。
ブロックを作っているプラグインの作者の方は、もう一つ。
Interactivity APIで、これまで通っていた割り当ての書き方が、7.1.4から拒否されるようになっている可能性があります。更新後にデバッグログを開いて、_doing_it_wrong の通知が出ていないかを見ておいてください。
次の自分に渡すメモ
10月30日、7.1.4のメモ。
件数は22件、公式の一覧では17項目。どちらで数えても、言っていることは同じ。
ログインなしで狙えるのは2件。更新中の窓と、カスタマイザーの未公開の変更。
更新中の窓は、セキュリティプラグインの外で起きる。サーバー側の .htaccess に1行。ルートの、WordPressの記述より上に。
upgradeフォルダーの中には置かない。掃除で消える。
自動更新は「入っているはず」で済ませない。版を見る。保守先も見る。
7.1.3から3週間で次が来た。次の版も、たぶんそう遠くない。
出典
いずれも2026年10月30日に確認。
WordPress 7.1.4（公式ニュース）：https://wordpress.org/news/2026/10/wordpress-7-1-4/
WordPress 7.1.4 Security Release（Patchstack・更新中のRCEの解説と緊急度の評価）：https://patchstack.com/articles/wordpress-7-1-4-security-release/
WordPress 7.1.4: 22 security fixes, including one in the updater itself（Wordify・17項目と22件の数え方）：https://wordify.com/blog/wordpress-7-1-4-security-release/
WordPress 7.1.4 Fixes 22 Security Flaws（Cyber Security News）：https://cybersecuritynews.com/wordpress-7-1-4-fixes-security-flaws/
コメント