WordPress 7.1.4公開、脆弱性12項目を修正

WordPressは2026年10月28日、セキュリティリリースの7.1.4を公開しました。日本語版のリリースアーカイブには、同じ日付で旧系列の7.0.8も載っています（公式アナウンスは7.0.8に触れていません）。公式アナウンスが挙げている脆弱性は12項目で、アップグレード処理でのリモートコード実行の可能性や、複数の保存型XSSが含まれます。自動更新が無効のサイトや、テーマ・プラグインを自作している開発者は、更新の状態を確認しておきたいところです。

7.1.4で修正された脆弱性の一覧
Interactivity APIとブロックの保存型XSSは、ブロックを自作する開発者にも関係する
更新の確認とバックポートの状況
参考にした公式情報

7.1.4で修正された脆弱性の一覧

wordpress.org/newsの7.1.4告知が挙げている修正は、次のとおりです（脆弱性の12項目と、証明書の更新1項目）。

アップグレード処理の弱点（アップグレード中にリモートコード実行が起こりうる問題）
細工されたブロックマークアップによる保存型クロスサイトスクリプティング（XSS）
プライバシーデータ削除リクエストの作り方によって、保存型XSSにつながる問題
Interactivity APIの保存型XSS（複数の報告者がそれぞれ独立に発見）
Interactivity APIの保存型サービス拒否（DoS）
カスタマイザーの選択的リフレッシュにおける保存型XSS
Categoriesブロックの保存型XSS
特殊なユーザーログイン名による保存型XSS
未公開のカスタマイザー変更セットが、未認証のユーザーに見つかりうる問題
PlaylistブロックとImageブロックの保存型XSS
コメントページネーションブロック（core/comments-pagination-nextとcore/comments-pagination-previous）の保存型XSS
投稿のノートについて、投稿の編集権限を持たない特権ユーザーがノートを読めてしまう問題

セキュリティ更新の一つとして、eMudhraの失効に対応した、同梱ルート証明書の更新も含まれています。

Interactivity APIとブロックの保存型XSSは、ブロックを自作する開発者にも関係する

修正の多くは保存型XSSです。保存型XSSは、細工された文字列がデータベースに保存され、あとからそのページを表示したユーザーのブラウザで実行されてしまう種類の脆弱性です。今回はブロックマークアップ、Categoriesブロック、Playlistブロック、Imageブロック、コメントページネーションブロックなど、コアのブロックが複数挙がっています。

テーマやプラグインでブロックを自作している場合、コア側の修正に加えて、自分のコードでも出力の際のエスケープを確認しておくと安心です。たとえば、ブロックの属性値をそのままHTMLに出していないか、Interactivity APIで扱うデータを信頼できないまま描画していないかが確認ポイントです。アナウンスは個々の修正の技術的な詳細までは書いていないため、ここでの確認ポイントは筆者の一般的な見方です。

更新の確認とバックポートの状況

7.1.4は短期サイクルのリリースで、次のメジャーバージョンは7.2の予定（アナウンスでは12月8日予定）とされています。アナウンスには、セキュリティ修正が、修正の対象となるすべてのブランチ（現在は4.7まで）にバックポートされたと書かれています。バックポートは順次進められ、準備ができたものから公開されます。つまり、古い系列の修正版は一斉には出そろわず、バージョンごとに公開時期が異なる場合があります。

サイト運営者や開発者が確認したいことは次のとおりです。

管理画面の「ダッシュボード」→「更新」で、現在のバージョンと、更新が適用済みか
自動更新が有効か。無効にしている場合は、手動で7.1.4へ更新する
7.0系を使っているサイトは、同系列の最新に更新する（日本語版のリリースアーカイブに、2026年10月28日の7.0.8が載っています。公式アナウンスは7.0.8に触れていないため、修正内容は配布元で確認してください）
更新前のバックアップ（ファイルとデータベース）
更新後に、フロントの表示、コメント、ログインが問題なく動くか

日本語版のリリースアーカイブを見ると、7.1の公開（9月11日）から約7週間で、7.1.1、7.1.2、7.1.3、7.1.4と4回の更新が続いています。更新のたびにステージング環境で検証する運用は負担が大きいため、自動更新を許可しつつ、更新後の動作確認を短時間で済ませる仕組みを作っておくのが現実的だと考えます。あわせて、Interactivity APIの項目には外部の複数の報告者が並び、それぞれ独立に見つけています。自作ブロックでユーザー入力や投稿メタをそのままHTMLの属性に渡していないか、今回の機会に見直す価値があります。権限まわりを独自に拡張しているプラグインも、コアの判定を上書きしていないか確認しておきたいところです。これは筆者の見方で、サイトの性質によって最適な運用は変わります。

なお、アナウンスでは、WordPress 7.2 Beta 3も公開されており、該当するすべての修正が含まれていると書かれています。7.2を先に試している開発者は、Beta 3への更新も合わせて確認してください。