WordPress 7.1.1が公開。自分のブログは今すぐ更新すべき？セキュリティ修正11件の中身と自動更新の対象範囲

PR｜この記事にはアフィリエイト広告（A8.net）が含まれます。

WordPressの管理画面を開いたら更新の知らせが出ている。セキュリティの更新らしいけれど、押してサイトが壊れないか不安で、そのままにしている。個人でブログを運営していると、この状態で数日過ぎてしまうことがあります。

WordPress 7.1.1は、セキュリティ修正11件を含むメンテナンスとセキュリティのリリースです。日本語の公式ブログでは2026年9月18日に告知され、「セキュリティリリースのため、サイトをできるだけ早く更新することを推奨します」と書かれています。自動バックグラウンド更新に対応しているサイトでは更新が自動的に始まりますが、その対象から外れる設定にしている場合は、ダッシュボードの「更新」から自分で更新することになります。

WordPress.orgの公式リリース（日本語版と英語版）と、WordPress公式ドキュメントの更新に関する説明をまとめた解説です。情報確認日：2026年9月21日。

WordPress 7.1.1には何が入っている？

日本語の公式ブログ「WordPress 7.1.1メンテナンスとセキュリティのリリース」は、今回の中身を次のように示しています。新しい機能が増える更新ではなく、修正を届けるための更新です。

含まれるもの	件数
WordPressコアのバグ修正	17件
ブロックエディターのバグ修正	19件
セキュリティ修正	11件

公式のお知らせによれば、7.1.1は短期サイクルでのリリースで、次のメジャーリリースはバージョン7.2、2026年9月18日の時点では12月に予定されていると書かれています。英語版の原文は2026年9月17日（協定世界時）に公開され、日本語版はその翻訳です。

自分のブログは対象？どこで確認する？

対象になるのは、7.1.1より前のバージョンで動いているサイトです。7系以外を使っている場合も関係します。公式のお知らせには「これらの修正は、必要に応じて、セキュリティ修正の適用対象となるすべてのブランチ (現在は4.7まで) に任意の対応としてバックポートされています」とあり、日本語版には「バックポートは全てリリース済みです」という訳注が付いています。つまり、6系や5系のまま運用しているサイトにも、必要に応じてそのブランチ向けの修正版が用意されているという説明です。

ただし同じお知らせには「公式にサポートされているのは WordPress の最新バージョンのみです」とも書かれています。古いブランチの修正版が出ていることと、そのブランチが今後もサポートされることは別の話です。

自分のサイトの状態は、管理画面から確認します。公式ドキュメント「WordPress のアップグレード」は「新バージョンが利用できるようになると、WordPress の管理画面に更新メッセージが表示されます」と説明しています。メッセージが見当たらないときは、メニューから「ダッシュボード」→「更新」を開いてください。日本語版のお知らせは、この画面で「バージョン 7.1.1–ja に更新」をクリックすると案内しています。

修正された11件は、どんな内容？

公式のお知らせは、責任ある形で報告された11件を挙げています。ここでは、その記載をそのまま整理しました。「公式の記載にある前提」の列は、お知らせの文に誰の立場が書かれているかを写したものです。書かれていないものは「記載なし」としています。深刻度や攻撃の有無は公式が示していないため、補いません。

修正された箇所	公式の記載にある前提	報告者
wpautop() の保存型クロスサイトスクリプティング（XSS）	認証されていない訪問者。ただしコメントの承認が必要	Rafie Muhammad（Awesome Motive, Inc.）
HTML APIのset_modifiable_text() で、突然終了シーケンスを使いコメントから抜け出せる	記載なし	Jeremy Felt（WordPressセキュリティチーム）
カスタムヘッダーに対応する一部のテーマの格納型XSS	記載なし	Jeremy Felt（WordPressセキュリティチーム）
細工されたURLで、無効化されているテーマをWordPress.orgから自動的にインストールしてプレビューできる	記載なし	Paulos Yibelo、pwn.ai
インストール済みのネットワーク専用プラグインをネットワークで有効化できる	サイト管理者	Jesse McNeil
WP REST Templates Controllerでの認証済みパストラバーサル	認証済み	Anthropic
XML-RPCで、edit_cssのチェックを回避するcustomize_changeset投稿を公開できる	記載なし	Ben Bidner（WordPressセキュリティチーム）
任意の投稿の上書き	投稿者以上の権限	Anthropic
attachment_submitbox_metadata() でread_postのチェックが欠け、非公開の親投稿のタイトルが漏洩する	記載なし	HDWSec
権限付与の欠落により、下書きや承認待ち投稿のスラッグが漏洩する	投稿者以上の権限	hermanhms
ノートを含むコメントの親を変更できる	ログイン済みのすべてのユーザー	viridis

報告者名は日本語版のお知らせの表記に合わせています。英語版の原文では、10件目（スラッグの漏洩）はJakub Herman、11件目（コメントの親の変更）はJustin Hart（Viridis Security）と書かれています。

用語を簡単に補うと、保存型（格納型）クロスサイトスクリプティングは、サイトに保存された内容を経由して、訪問者のブラウザーで意図しないスクリプトが動いてしまう問題です。パストラバーサルは、本来読み書きさせない場所のファイルにたどり着けてしまう問題を指します。

一覧を読むと、「投稿者以上の権限」「ログイン済みのすべてのユーザー」「サイト管理者」のように、そのサイトにアカウントを持っている人が前提として書かれた項目が複数あります。ログインできる人が増えるほど関係する項目も増える、という読み方はできます。ただし、アカウントが自分1人だけなら影響がないと公式が書いているわけではありません。wpautop() の項目のように「認証されていない訪問者」と明記されたものもあります。

今日やること：確認から更新までの手順

1. サイトのバックアップを取ります。公式ドキュメントは「始める前にサイトをバックアップすることをおすすめします。そうすれば、何か問題が発生しても簡単にサイトを元に戻せるからです」と書いています。
2. 管理画面で「ダッシュボード」→「更新」を開きます。
3. 「バージョン 7.1.1–ja に更新」をクリックします（公式ドキュメント「WordPress のアップグレード」では、このボタンを「いますぐ更新」と書いています）。これが公式ドキュメントのいうワンクリック更新で、ボタンを押したあとは自動で進みます。
4. 更新が終わったら、トップページと記事ページの表示、管理画面へのログイン、投稿の編集画面を開いて確かめます（この確認項目は筆者の提案です）。キャッシュ系のプラグインやサーバー機能を使っている場合、公式の更新手順ではキャッシュをクリアするよう案内されています。

公式ドキュメントは「ワンクリック更新はほとんどのサーバーで動作します。問題がある場合は、おそらくファイルシステムの権限に関することが原因でしょう」と説明しています。権限の問題があるときは接続用認証情報（FTP）を求めるダイアログが出ます。「更新の失敗」というメッセージが出続ける場合は、FTPでWordPressディレクトリから .maintenance ファイルを削除するよう案内されています。ワンクリック更新が通らないときのために、ファイルを入れ替える手動更新の手順も同じページにまとまっています。

自動更新に任せてよい場合と、自分で更新した方がよい場合

自動バックグラウンド更新はWordPress 3.7で導入された仕組みです。公式ドキュメント「自動バックグラウンド更新の設定」は「デフォルトでは (メンテナンスやセキュリティのための) マイナーリリースおよび翻訳ファイルのみがこの自動更新の対象になります」と書いています。7.1.1はメンテナンスとセキュリティのリリースなので、この初期設定の対象に当てはまります。なお、メジャーリリースの扱いは資料によって説明が異なります。英語版の「Upgrading WordPress」は、5.6より前からあるサイトはマイナーと翻訳ファイルだけ、5.6以降に新規インストールしたサイトはメジャーも初期設定で自動更新の対象（バージョン管理のチェックアウトを検出した場合は除く）と書いています。日本語版の「WordPress のアップグレード」にも、5.6以降の新規インストールではメジャーを含む自動更新が実現し、管理画面から設定を切り替えられるという記載があります。

更新の種類	公式ドキュメントに書かれた初期設定
コアのマイナー更新（メンテナンス・セキュリティ）	自動更新の対象
翻訳ファイル	自動更新の対象
コアのメジャーリリース	5.6より前からあるサイトは対象外（日本語版ドキュメントでは WP_AUTO_UPDATE_CORE の初期値は minor）。英語版ドキュメントでは5.6以降の新規インストールは対象
コアの開発版	開発版を運用しているサイトのみ対象
プラグイン	無効（WordPressセキュリティチームによる緊急のセキュリティ配信は例外）
テーマ	無効（同上）

初期設定のまま使っていて、自動更新を止める設定を入れていないのであれば、7.1.1は待っていても適用される見込みです。公式ドキュメント「WordPress のアップグレード」は、FTP情報を毎回入力せずにワンクリック更新ができる環境なら、ほぼ確実に自動バックグラウンド更新が行われると説明しています。ただし公式のお知らせは「更新プロセスが自動的に始まります」と書いているだけで、いつ終わるかまでは示していません。任せる場合でも、ダッシュボードの「更新」画面を一度開いて、実際に上がったかを自分の目で確かめる形にしておくと確実です。これは筆者の提案です。

自分で更新した方がよいのはどんなとき？

• wp-config.php に define( 'AUTOMATIC_UPDATER_DISABLED', true ); を書いている、または WP_AUTO_UPDATE_CORE を false にしている場合。公式ドキュメントでは、これらがすべての自動更新、またはコアの自動更新を無効にする設定として説明されています。
• automatic_updater_disabled や auto_update_core のフィルターで自動更新を制御するコードやプラグインを入れている場合。
• WordPressのディレクトリやその親ディレクトリに .git や .svn などのバージョン管理フォルダーがある場合。公式ドキュメントは、こうした環境でも自動更新させたいときに automatic_updates_is_vcs_checkout フィルターを使う方法を案内しています。
• レンタルサーバー側の管理ツールで自動更新を切っている場合。
• プラグインとテーマの更新もたまっている場合。これらは初期設定では自動更新の対象外なので、コアが自動で上がってもそのまま残ります。

自分の設定がどれに当てはまるか分からないときは、設定ファイルを探すより先に更新画面を開く方が早く済みます。「バージョン 7.1.1–ja に更新」のボタンが出ていれば、その場で押せば終わります。出ていなければ、管理画面に表示されているWordPressのバージョンが7.1.1になっているかを確かめてください。

更新の前に気をつけることは？

公式ドキュメントは、アップグレード処理が「メインの WordPress インストールを含むすべてのファイルとフォルダーに影響を与えます」と注意しています。WordPressの動作に必要なコアファイルがすべて入れ替わるため、コアファイルを直接書き換えている場合、その変更は消えます。手動更新の手順には、デフォルトテーマを名称変更せずに直接書き換えた場合も、上書きで変更が失われるという注意が添えられています。心当たりがあるなら、更新前にその箇所の控えを取ってください。

まとめ：今日どう判断する？

WordPress 7.1.1はセキュリティ修正を含むリリースで、公式はできるだけ早い更新を推奨しています。個人ブログでやることは、バックアップを取る、ダッシュボードの「更新」を開く、更新する、の3つです。自動更新に任せている人も、画面を開いて実際に上がったかを1回だけ確かめておくと、あとで迷いません。

公式は11件の深刻度を公開していないので、「この内容なら自分のブログは後回しでよい」と判断するための材料は、2026年9月21日の時点では公開されていません。判断に迷うときは、まず原文を読んでください。

自分のブログの設定をまとめて見直すのであれば、Cloudflareで検索は残してAI学習だけ断れるようにを読んでいただくと、検索エンジンのクロールは残したままAIの学習利用だけを断る設定が、どのプランのどこにあるのかが分かります。