WordPress 7.1.4は10月28日に出て、公式は直ちに更新するよう勧めた ── 担当サイトの版を一覧にして更新の期限を決める13項目（2026年10月時点）

目次

1. 01 何が書いてあるか — WordPress 7.1.4は、複数の領域のセキュリティ修正と、同梱の証明書の更新を入れた、10月28日のリリース
   1. 告知が並べた修正を、6つの領域に分ける
   2. 告知が書いていないこと
   3. 更新の方法と、古い枝への補修
2. 02 なぜ・背景 — 更新の通知を待つ前に、担当サイトの版を一覧にしておく理由
   1. 6週間弱の間に、7.1系の更新が4回出た
   2. 「自動更新で届く」は、期限の代わりにならない
   3. 古い枝の補修は、期限が読めない
3. 03 用語 — 出てくる言葉を、先にそろえる
   1. マイナーな版と、メジャーな版
   2. バックポート（補修）
   3. 保存型のXSS
   4. 枝（ブランチ）
   5. 同梱のルート証明書
   6. サイトヘルス
4. 04 型別 — 版を一覧にして、期限を決める手順
   1. 🅰 適用範囲 — この記事が向いているサイト
   2. 🅱 この記事が確かめていないこと
   3. 🅲 手順1 — 担当サイトを1枚の表に書き出す
   4. 🅲 手順2 — 版を、3か所で見る
   5. 🅲 手順3 — 版ごとに、期限の案を割り当てる
   6. 🅲 手順4 — 更新の後に、確かめる所
5. 05 明日、担当サイトで確認できることチェックリスト
6. 06 代替・他の選択肢 — 更新を、誰が、いつ行うか
   1. 3つの運用の形と、期限の決め方
   2. 古い枝のサイトに、できること
   3. プラグインとテーマは、別の話
   4. 同梱の証明書の更新を、どこで確かめるか
7. 07 当サイトで確かめたこと — 公開ページ8本と、WordPressの入り口を調べた結果
   1. 8ページに、WordPressの痕跡は無かった
   2. 入り口の5か所は、404だった
   3. 当サイトで確かめていないこと
8. 08 このテーマは、ここまで
   1. 7.1.1と7.1.2の、5日の間隔
   2. 7.1.3の7件の修正
   3. PHPの更新と、WordPressの更新は別
   4. 証明書の件
   5. 担当サイトの一覧づくりと、7.2の予定
   6. 2026年10月29日 — この記事の確認日
9. 09 この記事のまとめ

01 何が書いてあるか — WordPress 7.1.4は、複数の領域のセキュリティ修正と、同梱の証明書の更新を入れた、10月28日のリリース

2026年10月28日に、WordPress公式のニュースが「WordPress 7.1.4」を告知した。分類はReleasesとSecurityの2つで、書いたのはAaron Jorbinである。告知は、これがセキュリティの修正を含むリリースで、サイトを直ちに更新するよう勧める、という趣旨で始まる。この記事は、修正の技術的な中身の解説よりも、担当しているWordPressのサイトを一覧にして、版ごとに更新の期限を決める手順に絞る。個々の修正が自分のサイトに当たるかどうかは、既存の解説記事（7.1.3を扱った記事）が機能ごとの突き合わせを書いているので、そちらに任せる。

告知が並べた修正を、6つの領域に分ける

告知は、修正を1項目ずつ書き、それぞれの発見者の名前を添えている。筆者が数えると、告知の箇条書きは13本で、セキュリティの修正が12本、同梱の証明書の更新が1本である。Interactivity APIの2本を1つにまとめると、12項目になる。ここでは、機能の近さで6つの領域に分けて読む。

表に出ていない13本目が、同梱のルート証明書の更新である。告知は、eMudhraの失効を受けて更新した、と書く。これは脆弱性の修正ではなく、証明書の一覧の入れ替えである。05章でも06章でも、別の扱いにする。

告知が書いていないこと

告知に書かれていなかったことを、先に並べておく。この記事が出す期限の案は、この「書かれていない部分」を埋めるものではなく、書かれていないまま決める手順だからである。

• 各項目の影響を受ける版の範囲は、筆者が読んだ範囲の本文には書かれていなかった。
• 各項目の共通の識別番号（CVE番号）は、読んだ範囲の本文には書かれていなかった。この記事も番号を書かない。
• 実際に悪用された例があるかどうかは、告知には書かれていなかった。
• どの項目が、どの条件（ログインの有無、権限の種類）で起きるかの詳細は、項目ごとの短い説明にとどまる。

攻撃の手順は、この記事では書かない。読者が持ち帰るのは、更新の期限と、確認の順番である。

更新の方法と、古い枝への補修

告知は、更新の方法を2つ挙げる。WordPress.orgからダウンロードする方法と、管理画面の「更新」から「今すぐ更新」を押す方法である。バックグラウンドの自動更新が有効なサイトは、自動で更新されると書く。

もう1つ、古い枝の扱いについて書く。修正は、セキュリティ修正の対象になっているすべての枝へ、好意として補修（バックポート）される。告知の時点で、対象は4.7の枝までだとする。そのうえで、積極的に支えているのは最新の版だけだと書き、補修は、用意ができたものから順に配られていく、と続ける。告知の時点では、この補修は進行中と書かれていた。2026年10月29日に公式のリリース一覧を開くと、7.0.8から4.7.39まで、各枝に10月28日付の版が並んでいた。各枝の版に、どの修正が入っているかは、変更履歴で確かめる必要がある。最後に、WordPress 7.2のBeta 3も、該当する修正を含んで出ている、と書く。次の大きな版7.2は、12月8日に出る予定とのことである。

02 なぜ・背景 — 更新の通知を待つ前に、担当サイトの版を一覧にしておく理由

6週間弱の間に、7.1系の更新が4回出た

当サイトの過去の記事が記録した日付と、今回の告知を並べると、7.1系の更新は、9月17日から10月28日までの41日間に4回出ている。

• 2026年9月17日 — 7.1.1（当サイトの過去記事の記録）
• 2026年9月22日 — 7.1.2（当サイトの過去記事の記録）
• 2026年10月6日 — 7.1.3、セキュリティの修正7件（WordPress公式ニュース）
• 2026年10月28日 — 7.1.4、セキュリティの修正と、証明書の更新（WordPress公式ニュース）
• 2026年12月8日 — 7.2の予定（7.1.4の告知）

7.1.3と7.1.4は、22日の間隔である。1か所のサイトなら、通知が来たときに更新すれば済む。10か所、20か所のサイトを預かる人は、通知が来る前に、どのサイトがどの版にいるかを知っていないと、期限を決められない。

「自動更新で届く」は、期限の代わりにならない

公式の文書（Upgrading WordPress）は、背景の自動更新が、初期の状態で、マイナーな版（保守とセキュリティ）に対して動く（5.6以降の新規インストールは、メジャーな版も自動）、と書く。一方で、自動更新を止める手段が、設定にいくつも用意されていることも、同じ文書が書く。設定ファイルの定数で全体を止める方法、コアの自動更新の範囲を絞る方法、フィルターで止める方法である。さらに、1クリックの更新が失敗する場合は、おそらくファイルを書き換える権限の問題だ、と公式は書く。

筆者の読みでは、これは「自動更新に任せているサイトでも、止まっていないことを、版の数字で見に行く日が要る」という意味になる。止まっているサイトは、告知が出ても、静かに古い版のまま残る。

古い枝の補修は、期限が読めない

7.1.4の告知が書く補修は、好意として、用意ができたものから順に配られる、と告知の時点では進行中だった。翌日の公式のリリース一覧には、各枝の10月28日付の版が並んでいる。ただし、各枝の版にどの修正が入っているかは、変更履歴で確かめる必要がある。公式のセキュリティのページも、積極的に支えているのは最新の版だけで、古い版への補修は、重大な修正が自動更新で届くようにするための好意だ、という趣旨で書く。したがって、古い枝のサイトでは、自分の枝に10月28日付の版が出ているかを、一覧で先に確かめる。出ていれば、その版の変更履歴を見て、更新の日を決める。出ていなければ、日付つきで見に行く形にする。

03 用語 — 出てくる言葉を、先にそろえる

マイナーな版と、メジャーな版

バックポート（補修）

バックポートは、最新の版で直した修正を、古い版にも当てて配ることである。7.1.4の告知では、4.7の枝まで対象になりうる、と書く。ただし、告知は、積極的に支えているのは最新の版だけで、補修は好意であり、順に配られている、とも書く。

保存型のXSS

枝（ブランチ）

枝は、7.1系、7.0系、6.9系のように、同じ前の数字を持つ版のまとまりである。この記事で「古い枝」と書くのは、最新の7.1系より前の枝のサイトを指す。

同梱のルート証明書

WordPressは、外のサーバーとつなぐときに、どの認証局を信頼するかの一覧を持っている、と筆者は考えている。この一覧が、WordPress本体と一緒に配られているものを、この記事では同梱のルート証明書と呼ぶ。告知は、eMudhraの失効を受けて更新した、とだけ書く。どの証明書を入れ替えたかは、読んだ範囲の本文には書かれていなかった。

サイトヘルス

管理画面の「ツール」にある、サイトの状態の診断の画面である。公式の文書（Site Health screen）によれば、「ステータス」と「情報」の2つの画面があり、「情報」には、WordPressの版、有効なプラグインとテーマの数、サーバーの設定などが並ぶ。この画面は、情報を見る場所で、設定を変える場所ではない、と文書は書く。

04 型別 — 版を一覧にして、期限を決める手順

🅰 適用範囲 — この記事が向いているサイト

この記事は、WordPressで動いている、1つ以上のサイトを担当している人向けである。自分のサイトがWordPressかどうか分からない人は、05章の最初の項目で、まず確かめる。当サイトはWordPressではないので、7.1.4の修正は当てはまらない（07章）。

🅱 この記事が確かめていないこと

• 7.1.4の各項目の、影響を受ける版の範囲（告知の本文に見当たらなかった）
• 各枝の版に、どの修正が入っているか（変更履歴を、この記事では確かめていない）
• 同梱のルート証明書の中身と、どの証明書が入れ替わったか
• プラグインとテーマ側の更新の有無（告知はコアの話）
• 日本の事業者（ホスティング・制作会社）ごとの、自動更新の運用の違い

🅲 手順1 — 担当サイトを1枚の表に書き出す

表の列は、サイト名、アドレス、版、枝、自動更新、補修の待ち、バックアップの最終日、期限日、の8つで足りる。表は、紙でも表計算でもよい。大事なのは、版の列を、記憶ではなく、管理画面で開いた数字で埋めることである。

🅲 手順2 — 版を、3か所で見る

版を見る場所は、3つある。管理画面の「更新」の画面は、いちばん確かである。ダッシュボードの「更新」を開くと、いまの版と、更新できる版が出る。サイトヘルスの「情報」は、同じ版に加えて、有効なプラグインとテーマ、ユーザーの登録の可否まで、1画面に出る。管理画面に入れないサイトでは、公開ページのソースに、生成元の表示（generatorのmeta）が出ていることがある。ただし、これは版を隠す設定で消せるので、「出ていない」ことは、版が新しい証拠にならない。

🅲 手順3 — 版ごとに、期限の案を割り当てる

更新の期限は、公式の文書に基準があるわけではない。次の表は、筆者の案である。公式の告知が「直ちに」と勧めたことを出発点に、サイトの状態ごとに、確かめる日を割り当てた。日数は、サイトの運用に合わせて書き換えてよい。

最後の行は、筆者の判断である。告知は、細工したユーザー名で保存型のXSSが起きる項目を挙げている。ユーザーの登録を受け付けるサイトは、ユーザー名を、外の人が決められる。そのため、先に確かめるのが無難だ、というのが筆者の読みである。告知が、登録を受け付けるサイトを優先せよと書いているわけではない。

🅲 手順4 — 更新の後に、確かめる所

更新の後に確かめることは、4つある。1つ目は、管理画面の「更新」の画面で、版が7.1.4になっていること。2つ目は、公開ページを、あらかじめ決めた3ページ（トップ、ログイン画面、問い合わせのフォーム）で開き、表示が崩れていないこと。3つ目は、外のサービスとつないでいる機能（メールの送信、決済、地図）が、つながること。4つ目は、サイトヘルスのステータスで、更新前になかった「重要な問題」が増えていないことである。

公式のドキュメント（Updating WordPress）は、更新の前に、バックアップを取っておくとよい、と書く。更新のあとに問題が起きたら、バックアップから戻し、前の版のファイルに置き換えることもできる、とも書く。

05 明日、担当サイトで確認できることチェックリスト

以下は、担当しているWordPressのサイトを一覧にして、7.1.4に向けた更新の期限を決めるための13項目である。1〜5番目は版の一覧づくり、6〜9番目は自動更新と古い枝の確認、10〜11番目は、サイトの条件と、証明書の更新に関わる部品の確認、12〜13番目は、更新の後に確かめる所と、期限の記入である。1項目は5分以内でできる。チェックの状態は、お使いのブラウザに保存され、サーバーには送られない。

• 担当しているサイトを、メモ帳か表計算に1行ずつ書き出し、サイト名、アドレス、管理者の連絡先を書く。WordPressかどうか分からないサイトの行には「不明」と書く
• 1つ目のサイトの管理画面で、ダッシュボードの「更新」を開き、表示されているWordPressの版の数字を、表の「版」の列に書き写す（残りのサイトも同じ方法で書き写す）
• 公式ニュースのWordPress 7.1.4の告知を開き、公開日が2026年10月28日であることを確かめ、表の上に「最新は7.1.4（2026年10月28日）」と1行書く
• 表の各行の版を見て、「7.1系」「7.1系より前」「不明」のどれかを、「枝」の列に書き分ける
• 「7.1系」の行のうち、版が7.1.4でない行に印を付け、印を付けた行の数を、表の上に書く
• 各サイトのサイトヘルスの「ステータス」を開き、バックグラウンドの更新が期待どおりに動いていない旨の項目が「重要な問題」に出ているかを、「有」か「無」で書く
• 各サイトのコアの自動更新が、有効か、無効か、分からないかを、管理画面の更新の画面か、管理会社への1通のメールで確かめ、表の「自動更新」の列に書く
• 設定ファイルで自動更新を止めていないかを、管理会社に1通のメールで聞く（公式の文書にある、AUTOMATIC_UPDATER_DISABLEDとWP_AUTO_UPDATE_COREの2つの名前を、メールに書いておく）
• 「7.1系より前」の行のサイトの更新の画面を開き、10月28日以降に、補修の版が届いているかを見て、「届いた」か「待ち」を、確かめた日付と一緒に書く
• 各サイトのサイトヘルスの「情報」の「WordPress」を開き、「Can anyone register on this site?」の行に相当する、誰でも登録できるかの欄を、「はい」か「いいえ」で書き、「はい」の行に印を付ける
• 各サイトで、外のサービスとつないでいるプラグインや機能（メール送信、決済、地図、予約）の本数を数えて書き、更新の後に1本ずつ、つながるかを見る予定を、表の備考に1行書く
• 各サイトの、更新の前のバックアップの最終日を、バックアップの画面で確かめ、データベースとファイルの両方が入っているかを、「両方」「片方」「不明」で書く
• 更新の後に開く3ページ（トップ、ログイン画面、問い合わせのフォーム）を、サイトごとに決めて、表の備考に書き、更新の期限の案の表に従って、各行の「期限日」の列に日付を書く

06 代替・他の選択肢 — 更新を、誰が、いつ行うか

3つの運用の形と、期限の決め方

更新の運用は、おおむね3つの形に分かれる。どれも、公式の文書が書く、自動更新の仕組みの上にある。ただし、どの形が良いかは、サイトの数と、止められる時間によって変わる。

「事業者に任せる」場合は、更新した日の連絡を、契約の中で受け取る形にする。連絡がないことを、更新が済んだことと読んではいけない。

古い枝のサイトに、できること

古い枝のサイトには、選べる道が3つある。最新の7.1系へ更新する。移行の前に、試験用の環境で、使っているプラグインとテーマが動くかを確かめる。自分の枝に10月28日付の版が出ていれば、その変更履歴を見て、更新の日を決める。出ていなければ、1週間ごとに見に行く日を決める。管理会社や制作会社に、補修と移行の予定を聞く。聞いた日と答えを、表に書く。どの道でも、公式のセキュリティのページが書くとおり、積極的に支えているのは最新の版だけである。古い枝を使い続けるなら、それは「補修の好意に頼る運用」だと、担当者の間で共有しておく。

プラグインとテーマは、別の話

7.1.4の告知は、WordPress本体（コア）の話である。公式の文書は、プラグインとテーマの自動更新は、初期の状態では、特別な場合に限って動き、WordPress.orgのAPIの応答で印が付いたものが対象になる、という趣旨で書く。そのうえで、管理画面の設定の画面については、読んだ範囲の文書では触れていなかった。担当サイトのプラグインとテーマの自動更新は、コアとは別に、サイトヘルスの「情報」で、1本ずつ確かめる。

同梱の証明書の更新を、どこで確かめるか

証明書の更新は、コアの更新に入っている。したがって、7.1.4に更新したサイトには入り、更新していないサイトには入らない。ただし、サーバーの側にも、証明書の一覧がある。ブラウザの外から外のサービスにつなぐ通信は、WordPressの一覧と、サーバーの一覧の、どちらを使うかが、つなぎ方によって変わりうる。これは、既存の記事（eMudhraの記事）で、サーバー側の確かめ方を書いた。ここでは、WordPressの側は、コアの更新で入ることだけを押さえる。

07 当サイトで確かめたこと — 公開ページ8本と、WordPressの入り口を調べた結果

2026年10月29日の朝に、当サイトの公開ページ8本と、WordPressの管理画面などの入り口を、外から調べた。当サイトは、WordPressを使っていない。したがって、7.1.4の修正は当てはまらない。それでも調べたのは、WordPressと見間違えられる痕跡が、外から見えるかどうかを、版の話の確認として手元の記録に残すためである。

8ページに、WordPressの痕跡は無かった

開いたのは、トップページ、AI Ronのブログの一覧と記事1本、解説記事の一覧と記事1本、無料ツールの一覧、運営者ブログの一覧、お問い合わせの画面である。結果は次のとおりだった。

• 8ページすべてが、HTTPの状態200で開いた。
• HTMLの中に、「wp-content」と「wp-includes」の文字は、0件だった。
• 生成元を示すmetaタグ（generator）は、0件だった。
• 「wordpress」の文字は、トップページや一覧に数件あった。当サイトが書いたWordPressの記事の題名やリンクの文字である。

入り口の5か所は、404だった

WordPressが標準で持つ入り口の5か所（ログイン画面、管理画面、readme、JSONの入り口、XML-RPC）に、外から1回ずつアクセスした。5か所とも、HTTPの状態404が返った。また、トップページの応答ヘッダーに、PHPの版を示すX-Powered-Byの行は、出ていなかった。

当サイトで確かめていないこと

• 8ページ以外の、公開ページ（全ページは調べていない）
• ログインしたあとの画面（開いていない）
• 当サイトとは別の場所に置かれた、WordPressのサイトがあるか（このサイトの範囲では調べていない）

この結果が言えるのは、当サイトの外から見える範囲に、WordPressの痕跡が無かった、ということまでである。「WordPressを使っていないので安全だ」とは、言えない。版の数字が見えなくても、更新の確認は、サイトの種類ごとに別に要る。

08 このテーマは、ここまで

WordPressの更新の話は、これまでにも書いてきた。7.1系の記録を、日付の順に挙げる。

7.1.1と7.1.2の、5日の間隔

WordPressは5日の間に、セキュリティ更新が2回出た ── 担当サイトの版・自動更新・バックアップを一覧で確かめる13項目（2026年10月時点）は、9月17日と22日の2回の更新を扱い、担当サイトの版、自動更新、バックアップを一覧にする表を書いた。この記事の手順1は、その表に、期限日の列を足した形である。

7.1.3の7件の修正

WordPress 7.1.3の7件の修正は、それぞれ別の機能に当たる ── 自社のWordPressで使っている機能と突き合わせて確かめる13項目（2026年10月時点）は、10月6日の7件の修正を、機能の名前で突き合わせた。7.1.4の個々の修正が、自社のサイトで使っている機能に当たるかどうかは、同じ読み方で確かめられる。

PHPの更新と、WordPressの更新は別

WordPressの更新は要らないが、PHPの更新は要る。公式の記事が書いたこと ── サイトヘルスで版を見て、事業者に確かめる13項目（2026年10月時点）は、WordPressの更新と、PHPの更新が別の話であることを書いた。7.1.4に更新しても、サーバーのPHPの更新は、それとは別に要る。PHPの更新を確かめる場合に、版の表示だけで済ませてはいけない理由は、PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 修正が入ったかを値で確かめる4つの方法と、3本目の知らせ（CVE-2026-115560）を当サイトで確かめた記録で書いた。

証明書の件

eMudhraの中間証明書の件は、認証局eMudhraの中間証明書8枚の秘密鍵が漏れた。テスト用サイトによればブラウザは遮断済みで、残るのはブラウザの外の通信 ── 自社と担当サイトの信頼の経路を確かめる13項目（2026年10月時点）と、認証局の中間証明書8枚の秘密鍵が漏れた週、当サイトのサーバーの中からつなぐ通信は、漏れた証明書を通していた ── AIの知らせを自分で測り直して、塞いだ記録で書いた。今回の7.1.4が、同梱の証明書を更新したことは、この件が、サーバーだけでなく、CMSの更新にも波及した例である。

担当サイトの一覧づくりと、7.2の予定

PHPの台帳の作り方は、PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要る ── 台帳の8列を埋めて確かめる13項目（2026年10月時点）で書いた。WordPress 7.2の日程は、WordPress 7.2は12月8日に出る予定で、ベータは10月20日に始まる ── 日程の各日付に試験環境でやることを割り当てる13項目（2026年10月時点）で扱った。7.1.4の告知は、7.2の予定が12月8日のままであることを、確かめる材料になる。

2026年10月29日 — この記事の確認日

この記事の内容は、2026年10月29日に、WordPress公式のニュース2本、ドキュメント4本、リリースの一覧ページ2本、Cloudflareのブログ1本、Mozillaのバグ票1本を開いて確かめた時点のものである。各枝の版の変更履歴や、告知の追記があったときは、日付つきで追記する。