WordPress 7.1.4 は緊急のセキュリティリリース — 22件の脆弱性と更新時の確認手順
2026年10月28日に WordPress 7.1.4 が公開されました。セキュリティリリースであり、WordPress 公式は「サイトを直ちに更新すること」を推奨しています。公式ドキュメントによれば修正された脆弱性は22件。コア更新処理の競合状態による遠隔コード実行 (RCE) や、未公開のカスタマイザー変更が未認証の訪問者に漏れる情報開示が含まれます。結論として、7.1 系を使っているなら今日中に 7.1.4 へ、それ以外の系統でも対応するパッチ版へ上げるのが妥当です。
7.1.4 で修正された内容
公式リリース告知とバージョンドキュメントが挙げている主な修正は次のとおりです。
- コア更新中の競合状態による遠隔コード実行 (報告: Umut Bayram)
- 未公開のカスタマイザー変更 (changeset) が未認証の訪問者に露出する情報開示 (報告: Antonio Lorensius Silaban)
- Interactivity API 関連の複数のストアド XSS と、サービス拒否 (DoS) の問題
- ブロック区切り文字の空白処理、カテゴリーブロック、コメントページ送り・投稿ナビゲーションリンクのラベル、画像・プレイリストブロックに関する XSS および堅牢化
- カスタマイザーの選択的更新 (selective refresh) におけるストアド XSS
- 個人データ消去リクエスト画面のストアド XSS、マルチサイトのネットワークユーザー画面でのユーザー名エスケープ漏れ (いずれも報告: Anthropic)
- コメントモデレーション権限だけで、編集権限のない投稿のノートを読み書き・削除できた権限不備
- eMudhra の証明書失効に伴う同梱ルート証明書の更新
ストアド XSS とは、投稿内容などに保存された悪意あるコードが、他のユーザーの画面で実行される脆弱性です。
どれくらい急ぐべきか — 権限要件から考える
公式ドキュメントは各脆弱性に必要な権限を明記しています。XSS の多くは「寄稿者以上」「投稿者以上」「編集者以上」のログインアカウントを前提とします。つまり、管理者だけが投稿する小規模サイトでは即座に悪用される可能性は相対的に低いと言えます。
一方で、優先度を上げるべきサイトもはっきりしています。会員登録を開放している、外部ライターや複数の編集者がいる、プラグインが独自ロールを配っている、マルチサイトで運用している、といったケースです。寄稿者レベルのアカウントが1つでも奪われれば、保存した内容が管理者の画面で実行され得ます。
加えて、カスタマイザーの情報開示はログイン不要で成立します。未公開のデザイン変更やキャンペーン準備中の内容を扱っているなら、この1点だけでも更新理由になります。コア更新中の RCE も、更新が走っている短い時間帯が条件とはいえ、成立すればサイト全体の乗っ取りにつながる種類の問題です。
7.1 以外を使っている場合の更新先
今回の修正はセキュリティ更新の対象となるブランチ (現時点で 4.7 まで) にバックポートされ、公式ドキュメント上ではすでに各版が公開済みとされています。7.0 は 7.0.8、6.9 は 6.9.11、6.8 は 6.8.12、6.7 は 6.7.11、6.6 は 6.6.11、6.5 は 6.5.14、6.4 は 6.4.14、6.3〜5.9 は 6.3.14 / 6.2.15 / 6.1.16 / 6.0.18 / 5.9.20 が該当します。4.6 以前はセキュリティ更新の対象外です。
影響する件数はブランチごとに異なり、7.0 と 6.9 は22件すべて、6.8・6.7 は20件、6.6 は19件、6.5・6.4 は17件、6.3〜5.9 は9件、5.8〜5.0 は6件、4.9 は4件、4.8・4.7 は2件とされています。ただし WordPress が公式にサポートするのは最新版のみという前提は変わりません。古いブランチに留まっている場合、今回のパッチ適用は応急処置であり、最新系への移行計画を別途立てる必要があります。
更新手順と、更新後に確認すること
- 管理画面の「ダッシュボード > 更新」から更新する。自動バックグラウンド更新が有効なサイトは自動で適用されるが、適用されたかを必ず確認する。
- 本番前にステージング環境があるなら、そこで先に適用して主要ページを確認する。ただしセキュリティリリースなので、検証に何日もかけない。
- 更新後、バージョン番号が 7.1.4 (または該当するパッチ版) になっているかを管理画面で確認する。
- 投稿の表示、フォーム送信、検索、会員向けページなど、コンバージョンに関わる動線を一通り触る。
公式の変更ファイル一覧には kses.php や Interactivity API のクラス、ブロックのレンダリング処理、カスタマイザーの選択的更新に関する JavaScript、Twenty Twenty テーマのプレビュー用スクリプトなどが含まれています。サニタイズと属性バインディングの許容範囲を狭める方向の修正であるため、開発者側では次の箇所を重点的に見るのが現実的です。
- Interactivity API のディレクティブを使う自作ブロックやテーマ — 属性バインディングが想定どおり動くか
- 画像ブロック・プレイリストブロック・カテゴリーブロック・コメントページ送りの出力を独自に加工している実装
- カスタマイザーに独自パーシャルを登録しているテーマ — 選択的更新のプレビュー挙動
- HTML を含むユーザー名や表示名を扱っていた画面 — エスケープ追加で見え方が変わる可能性
運用として詰めておきたいこと
7.1 系はこれで 7.1.1 から 7.1.4 までマイナー更新が続いています。月1回まとめて更新する運用では、公開済みの修正が当たっていない期間が長くなります。マイナー版の自動バックグラウンド更新は既定で有効ですが、ホスティングや wp-config.php の設定、ファイル権限、バージョン管理下でのデプロイ構成によっては動かないことがあります。「自動更新に任せている」と思っているサイトほど、実際に 7.1.4 が当たっているかを一度確認する価値があります。
なお 7.1.4 は短サイクルのリリースで、次のメジャーリリースである 7.2 は2026年12月8日が予定されています。今回の修正は 7.2 Beta 3 にも含まれています。12月の更新作業を見据えるなら、今回の適用で表示崩れや不具合が出た箇所を記録しておくと、メジャー更新時の確認範囲を絞れます。
まとめ
7.1.4 は機能追加のない純粋なセキュリティリリースで、延期する理由はほとんどありません。まず現在のバージョンを確認し、該当するパッチ版へ更新する。次に自動更新が実際に機能しているかを点検する。この2つを今週中に終えるのが、今回の告知に対する最小限の対応です。
