WordPress 7.1.4が2026年10月28日付（UTC）で公開されました。
今回のリリースは、WordPress本体に見つかった複数の脆弱性を修正するためのセキュリティ更新です。公式は速やかな更新を推奨しています。 現在7.1系を利用している方は、バックアップの状態を確認し、7.1.4への更新を進めましょう。
この記事では、公式発表と公式の詳細資料をもとに、主な修正内容とサイト運営者が行いたい対応を説明します。
- 1. 参考資料
- 1.1. 英語
- 1.2. 当ブログ関連記事
- 2. WordPress 7.1.4は、優先して適用したいセキュリティ更新
- 3. 主な修正内容を分かりやすく整理
- 3.1. 更新中に、不正なコードを実行される可能性
- 3.2. 保存した内容から不正な処理が動く「格納型XSS」
- 3.3. Interactivity APIに関係する複数の問題
- 3.4. 未公開情報とノートの権限に関する問題
- 3.5. 同梱のルート証明書も更新
- 4. 更新が相次ぐ背景
- 5. サイト運営者が行う更新対応
- 5.1. ① 現在のバージョンを確認する
- 5.2. ② バックアップを確保する
- 5.3. ③ 管理画面から更新する
- 5.4. ④ 更新後の表示と動作を確認する
- 6. 7.1.3や古いバージョンを使っている場合も確認を
- 7. 終わりに
参考資料
英語
当ブログ関連記事
WordPress 7.1.4は、優先して適用したいセキュリティ更新
2026年10月30日の確認時点で、最新の正式版はWordPress 7.1.4です。公式詳細資料では、今回の修正対象を計22件の脆弱性として説明しています。更新処理、ブロック、カスタマイザー、管理画面など、複数の機能に関係する更新です。
公式の説明には、複数の問題をまとめた項目もあります。そのため、発表の箇条書きの数と脆弱性の件数は一致しません。また、22件すべてが同じ条件・同じ危険度の問題という意味でもありません。
脆弱性とは、悪用されると不正な操作や情報漏えいなどにつながる、ソフトウェアの弱点のことです。通常どおりサイトが表示されていても、脆弱性がないとは限りません。
今回の修正には、攻撃する側に一定のユーザー権限が必要なものも含まれます。一方で、ログインしていない人への情報漏えいに関係する問題もあります。運用形態によって危険性は異なりますが、「一人で運営しているから更新しなくてもよい」と判断することはおすすめできません。
主な修正内容を分かりやすく整理
今回の修正対象を、大きく分けると次のようになります。
- WordPress本体の更新処理： 更新中に不正なコードの実行につながる可能性がある問題
- ブロックや管理画面など： 保存された不正なデータを通じてスクリプトが実行される問題
- Interactivity API： 複数のスクリプト実行の問題と、正常な処理を妨げる問題
- カスタマイザー： 未公開の変更内容の情報漏えいなど
- 投稿に付けるノート： 一部の権限設定で、操作できる範囲が広がってしまう問題
- 同梱のルート証明書： eMudhraの証明書失効に伴う更新
以下では、特に知っておきたい内容を説明します。被害の説明は、それぞれの脆弱性の種類についての一般的な解説も含みます。すべてのサイトで同じ攻撃が成立するという意味ではありません。
更新中に、不正なコードを実行される可能性
WordPress本体の更新処理に、処理のタイミングによってリモートコード実行につながる可能性がある問題が修正されました。
リモートコード実行とは、外部から対象のサーバーでプログラムを動かされることです。一般に、実行できるプログラムや権限によっては、ファイルの改ざんや情報の読み取りなどにつながるおそれがあります。
公式資料は、この問題を更新中の「競合状態」に関係するものと説明しています。競合状態とは、複数の処理が動く順番やタイミングによって、意図しない結果になることです。
ただし、本記事で確認した公式リリース案内と詳細資料だけでは、攻撃に必要な条件のすべては分かりません。これらの資料は、更新処理中の問題であることを示していますが、「誰でも、いつでもサイトを乗っ取れる」とまでは読み取れません。
更新処理に問題があると聞くと、更新そのものをためらうかもしれません。しかし、公式は今回の修正版への更新を案内しています。この発表を理由に更新を止めるのではなく、公式の案内に沿って対応しましょう。
保存した内容から不正な処理が動く「格納型XSS」
今回の修正には、複数の「格納型XSS」が含まれます。
XSSは、クロスサイトスクリプティングの略です。Webページに混入した不正なスクリプトが、そのページを開いた人のブラウザーで実行されてしまう問題を指します。
このうち格納型XSSは、不正な内容がサイト側に保存され、後からその内容を表示したときに動くものです。例えば、細工された内容を管理者が確認した際に、管理者としての操作を悪用されることが考えられます。
今回の対象には、ブロックの記述や個人データ消去リクエストなどが含まれています。ユーザー名の扱いについては、公式詳細資料では、複数のサイトを一括管理する「マルチサイト」のネットワークユーザー画面における安全性の強化と説明されています。通常の単独サイトのすべてのユーザー名に、同じ問題があると一般化しないようにしましょう。
なお、公式の詳細資料には「寄稿者以上」「投稿者以上」「編集者以上」などの条件が示された項目もあります。これらは、攻撃する側に一定の権限が必要であることを意味します。
例えば、ブロックの記述を利用する一部の問題は寄稿者以上、アップロードしたテキストファイルを利用するInteractivity Routerの問題は投稿者以上、個人データ消去リクエスト画面の問題は編集者以上と説明されています。権限は攻撃条件の一部であり、その権限さえあれば必ず攻撃できるという意味ではありません。
外部ライターなどにアカウントを渡しているサイトでは、更新とあわせて、各ユーザーに必要以上の権限を与えていないか確認しておくとよいでしょう。
Interactivity APIに関係する複数の問題
Interactivity APIは、公開ページのブロックに、クリックなどの操作に応じた動きを付けるためのWordPress標準の仕組みです。テーマやブロックが利用するため、サイト運営者が自分でプログラムを書いていなくても関係します。
今回、この仕組みに関係する複数のXSSとDoSの問題が修正されています。
DoSは「サービス拒否」の略で、正常な処理を妨げ、機能やサービスを利用しにくくすることです。DoSと聞くと大量のアクセスを想像しがちですが、不正な入力や保存された内容によって処理に支障が出る場合もあります。
未公開情報とノートの権限に関する問題
カスタマイザーでは、公開前の変更内容が、ログインしていない人に知られる可能性がある問題が修正されました。
これを「すべての下書き記事が漏れる問題」と捉えるのは正確ではありません。公表された対象は、カスタマイザーの未公開の変更内容です。
また、投稿に付けるノートについて、コメントを管理できるカスタム権限のユーザーが、本来編集できない投稿のノートを読み取り・編集・削除できる問題も修正されています。
複数人で運営するサイトでは、投稿だけでなく、内部のやり取りを誰が見られるかという点も大切です。
同梱のルート証明書も更新
今回の更新には、eMudhraの証明書失効に伴う、同梱のルート証明書の更新も含まれます。
ルート証明書は、HTTPS通信の接続先を信頼できるか確認する際の土台になるものです。これはWordPressに同梱される証明書群の変更であり、この発表だけを理由に、自分のサイトのSSL証明書を一律に交換する必要があるという意味ではありません。
参考リンク
更新が相次ぐ背景
WordPressのセキュリティチームは、今回の更新後の10月29日16時58分（UTC）に、セキュリティ改善活動の進捗を報告しました。
報告では、AIを活用した調査などを背景に脆弱性の報告が増え、報告内容の確認、修正、検証、配布の体制を強化していると説明しています。AIによる調査支援も利用していますが、報告の評価は最終的にセキュリティ担当者が判断する仕組みです。
更新が続くことだけで、攻撃被害の増加や新機能の品質低下を断定することはできません。今回の追加報告からは、問題を見つけ、修正を届ける取り組みが進んでいることも読み取れます。
ただし、これは個々の脆弱性を軽く見てよいという意味ではありません。運営者としては、更新通知を見逃さず、適用後の確認まで行うことが大切です。
サイト運営者が行う更新対応
① 現在のバージョンを確認する
まず、WordPress管理画面の「ダッシュボード → 更新」を開き、現在のバージョンを確認します。
自動更新に対応しているサイトでは、すでに更新されている場合があります。「自動更新を設定しているから大丈夫」と考えず、修正版になっていることを実際に確認することが大切です。
複数のサイトを管理している場合は、それぞれ確認してください。
② バックアップを確保する
手動で更新する前に、サイトを復元できるバックアップを確認します。WordPress公式も、更新前のバックアップを案内しています。
確認したいのは、主に次の2つです。
- データベース：投稿本文や各種設定など
- サイトのファイル：画像、テーマ、プラグインなど
レンタルサーバーの自動バックアップを利用している場合も、保存日時と復元方法を把握しておきましょう。
③ 管理画面から更新する
「ダッシュボード → 更新」で、WordPress本体の更新ボタンを押します。更新が完了したら、バージョンが修正版になっていることを確認してください。
管理を制作会社や保守担当者に依頼している場合は、「WordPress 7.1.4で修正された脆弱性への対応状況」を確認すると、用件が伝わりやすくなります。
④ 更新後の表示と動作を確認する
更新後は、日常的に使うページや機能を確認しましょう。
- トップページ、投稿、固定ページが表示されるか
- 管理画面にログインできるか
- 投稿や固定ページを編集できるか
- コメントや会員機能が正常に動くか
- 問い合わせフォームなどが動作するか
サイトが普段どおり表示されていても、セキュリティ上の問題がないとは限りません。
WordPress 7.1～7.1.3を利用している場合は、バックアップを確保し、動作確認の準備を整えたうえで、7.1.4への更新を進めてください。
7.1.3や古いバージョンを使っている場合も確認を
今回の問題はWordPress 7.1.3にも存在します。直前のセキュリティアップデートを適用していても、7.1.4への更新が必要です。
また、旧バージョンの系列も影響を受けます。公式のセキュリティ勧告には、主な修正版として次のバージョンが記載されています。
| 利用している系列 | 今回の修正版 |
|---|---|
| WordPress 7.1系 | 7.1.4 |
| WordPress 7.0系 | 7.0.8 |
| WordPress 6.9系 | 6.9.11 |
| WordPress 6.8系 | 6.8.12 |
| WordPress 6.7系 | 6.7.11 |
上表は主な系列の例です。この他、4.7系まで修正対象とされています。一方、4.6以前にはセキュリティ更新が提供されません。 また、利用中の系列によって含まれる機能が異なるため、今回の脆弱性の影響件数も異なります。
ただし、旧系列への修正提供は、今後も継続してサポートされることを保証するものではありません。 WordPress公式は、最新バージョンのみを積極的なサポート対象としています。
テーマやプラグインの互換性の事情で最新版に移行できない場合は、まず利用中の系列の修正版を確認し、そのうえで最新版への移行準備を進めましょう。
終わりに
WordPress 7.1.4は、更新処理やブロック、管理画面などに関係する複数の問題を修正するセキュリティリリースです。
2026年10月30日に確認した公式リリース案内と詳細資料には、今回の脆弱性について攻撃被害が広がっているとの記載はありません。ただし、これは「悪用されていないことが確認された」という意味ではありません。被害への言及がないことと、被害が存在しないことは区別して受け止めましょう。
また、WordPress本体の更新だけで、テーマ・プラグインやPHPまで更新されるわけではありません。それぞれの更新状況も別途確認してください。
現在のバージョンとバックアップを確認し、更新後に表示・動作を確かめる。 この基本を押さえながら、速やかに修正版を適用しましょう。
