WordPress 7.1.4が更新中の脆弱性を修正、すべてのサイトへの適用確認を

WordPressは2026年10月28日、アップグレード中にリモートコード実行を許す可能性がある弱点などを修正したバージョン7.1.4を公開しました。リリース告知は、直ちに更新するよう推奨しています。複数サイトを運営している場合、最初に行うべきことは、どの環境に実際に修正が入ったかを把握することです。

WordPressによると、自動バックグラウンド更新に対応するサイトでは処理が自動的に始まります。これは更新の開始方法の説明であり、すべてのサーバーで完了したという確認ではありません。有効になっている設定、古い保守チェックリスト、ホスティング会社の一般的な更新方針は、実際のバージョン確認の代わりにはなりません。

アップグレード処理自体が修正の対象

告知は、アップグレード処理の弱点を報告した人物としてUmut Bayram氏を挙げています。Interactivity API、カスタマイザーの選択的リフレッシュ、個人データ削除リクエストなどに関する保存型クロスサイトスクリプティングの問題や、保存型のサービス拒否の問題も列挙されています。eMudhraの失効を受け、同梱のルート証明書も更新されます。

ほかにも、未公開のカスタマイザー変更セットを認証なしで見つけられる問題や、対象投稿を編集できない権限ユーザーが投稿ノートを読める問題が修正されています。それぞれ異なる権限や情報露出の問題です。告知は、特定のサイトが攻撃されたことも、すべての問題で悪用条件が同じであることも示していません。

バージョン文書には、影響するコンポーネントや権限についての詳しい説明があります。個別環境を評価する管理者には有用です。対応するかどうかを決める運営者にとっては、直ちに更新すべきという推奨はすでに明確です。更新中の弱点は、修正を先送りする理由にはなりません。

更新の完了とサイトの動作を確認する

各サイトのダッシュボードで「更新」を開き、現在のバージョンを確認してください。現行の安定ブランチでは、このリリースの更新先は7.1.4です。更新がまだ表示される場合は「今すぐ更新」を使うか、ホスティング担当者に作業を依頼します。完了後にもう一度画面を開き、更新後のバージョンを記録してください。

WordPressの更新手順は事前のバックアップを推奨し、ワンクリック更新の失敗がファイルシステムの権限に関係する場合があると説明しています。そのため、保守記録にはサイト、インストール済みバージョン、バックアップの保存先、結果、未解決エラーを含めると役立ちます。失敗した更新は完了欄ではなく、対応中の作業一覧に残すべきです。

更新後は公開記事、管理者ログイン、重要な公開操作を確認してください。これはサイトが引き続き使えることを確認する作業であり、セキュリティ監査ではありません。準備済みのステージングとロールバックの計画を使い、バックアップと復元の確認が実際に実行できる復旧手順をカバーしているか確かめてください。

古いブランチには具体的な修正版の確認が必要

告知では、セキュリティ修正のバックポートは4.7ブランチまでを対象とし、配布作業が続いていると説明していました。現在のバージョン文書には4.7.39などの古いブランチ向け修正版が掲載され、4.6以前はセキュリティ更新を受け取れないと記されています。積極的にサポートされるのは最新のWordPressだけです。実際に使っているブランチに対応する修正版を確認してください。バックポートがあるだけで、古い環境がすべて安全になるわけではありません。

今日更新できないサイトがある場合は、バージョンと妨げになっているエラーをホスティング会社や保守担当者へ伝え、責任者を決め、復旧またはアップグレードの具体的な時刻を設定してください。修正の手配中は、そのサイトに合ったリスク抑制策の評価を求めます。バックアップ、ファイアウォール、後で更新するという約束を、脆弱性が修正済みである証拠と考えてはいけません。

同じ告知は、7.2 Beta 3にも該当する修正が含まれると説明し、7.2の公開予定日を12月8日としています。リリース一覧は、ベータテストと本番用リリースを区別しています。将来のメジャー版を待つことは、現在のセキュリティ更新を保留する理由にはなりません。