WordPress 7.1.4とは？22件の脆弱性修正と、更新中を狙う遠隔コード実行の中身【10月28日公開】

2026年10月28日（日本時間では29日の未明）に、WordPress 7.1.4が公開されました。10月6日の7.1.3から約3週間での更新で、直った脆弱性は22件です。公式は「セキュリティのリリースなので、すぐに更新することを勧める」としています。

結論から言うと、7.1.4は「今日のうちに更新を確かめておきたい」更新です。22件の中には、更新作業をしている数秒のあいだに、ログインしていない人からサーバー上でプログラムを動かされるおそれがある問題（遠隔コード実行）が含まれます。ただし、狙えるのは更新中のごく短い時間だけで、実際に悪用するのは難しいと評価されています。残りの多くは、寄稿者以上のアカウントが必要なものです。

この記事では、公式の発表に加えて、当社で7.1.3から7.1.4へのプログラムの変更点（差分）を読み、検証環境で実際に更新して確かめたことをまとめました。

この記事は2026年10月29日時点の情報です。

WordPress 7.1.4とは？修正された22件の脆弱性

7.1.4はセキュリティの修正だけを含む更新です。件数は資料によって数え方が違い、公式ニュースでは13項目にまとめられ、公式の解説ページ（HelpHub）では「22件」、セキュリティ企業のPatchstackは「17件の告知に22件」と数えています。ここでは、影響を受ける条件ごとに整理しました。条件はPatchstackの解説をもとにしています。CVE番号や深刻度の点数は、公開時点では示されていません。

XSS（クロスサイトスクリプティング）は、記事などに仕込まれたプログラムが、それを開いた人の画面で動いてしまう問題です。寄稿者以上が条件のものが多いので、ログインできるのが運営者1人だけのサイトでは、影響は小さめです。一方で、外部のライターや複数のスタッフにアカウントを渡しているサイトでは、早めの更新が大切になります。

このほか、eMudhra（電子証明書の発行会社）の証明書が失効したことにあわせて、WordPressに同梱されているルート証明書が更新されました。テーマ「Twenty Twenty」も3.3に上がっています。今回も2件は、Anthropic（AIのClaudeを開発する会社）が報告したものです。

いちばん重い「更新中を狙う遠隔コード実行」とは？

WordPressは本体やプラグインを更新するとき、ダウンロードしたファイルをいったんwp-content/upgradeというフォルダに展開してから、本来の場所へ置き換えます。7.1.3までは、この作業用のフォルダの名前が推測しやすく、更新している数秒のあいだ、そこに置かれたWordPress一式へ外からアクセスできてしまう余地がありました。

Patchstackは、更新中のごく短い時間を正確に狙う必要があることから、「現実的に悪用できるとは言いにくい」と評価しています。アカウントは不要ですが、条件はかなり厳しい問題です。公開時点で、実際に悪用されたという報告は見当たりません。

7.1.4では、次の3つの対策が入りました。

• 作業フォルダの名前の末尾に、ランダムな16文字を付ける
• upgradeフォルダに中身の一覧が表示されないよう、空の index.php を置く
• 本体の更新で、作業フォルダから wp-config.php（データベースの接続情報などを書いた設定ファイル）を写さない

当社の環境で確かめたこと

公開翌日の10月29日に、当社の保守先、当社サイト、検証環境の3つで状況を確かめました。

保守先のサイトは、翌日の時点でまだ7.1.3

当社が保守しているサイトは、10月29日の時点ではまだ7.1.3のままで、7.1.4にはなっていませんでした。公開から1日たっても、すべてのサイトが自動で上がるとは限りません。自分のサイトがどちらなのかは、後で紹介する方法で確かめてください。

当社サイトは、手で更新する前に7.1.4になっていた

当社のサイトは、手で更新する前に確かめたところ、10月29日の夜の時点ですでに7.1.4になっていました。公開されているファイルのうち、7.1.4で変わったもの5つを、WordPress.orgが公開している正しいファイルの指紋（チェックサム）と照らし合わせたところ、5つとも7.1.4と一致しています。作業用のupgradeフォルダは、外から開いても一覧が見えない（403）設定になっていました。

検証環境では、起動から16秒で自動更新された

7.1.3のままにしていた当社の検証環境（パソコンの中で動かしているWordPress）を起動したところ、起動から16秒後には、自動更新で7.1.4に置き換わっていました。手で更新するより先に、自動更新が動いたことになります。

ここで1つ分かったことがあります。自動更新が終わったあとのupgradeフォルダは空で、7.1.4で置かれるはずの index.php はありませんでした。続けて、同じ7.1.4をコマンドで入れ直すと（作業は18秒）、今度は index.php が作られ、作業フォルダの名前の末尾にランダムな16文字が付いていました。

プログラムを読むと、更新の前半（ファイルの展開）は更新前の版のプログラムで動き、後半の置き換えは新しい版のプログラムで動く順番になっています。つまり、フォルダの名前をランダムにする対策が働くのは、7.1.4になった「次の更新」からと考えられます。7.1.4に上げる1回目の更新そのものは、これまでと同じ手順で行われます。とはいえ、狙える時間がごく短いことに変わりはありません。気になる場合は、サーバー側でupgradeフォルダへのアクセスを止めておくと安心です（技術者向けの見出しで説明します）。

ここまでのまとめ

• 7.1.4は、22件の脆弱性を直すセキュリティ更新。すぐに更新するよう公式が勧めている
• ログイン不要の問題は2件。いちばん重い遠隔コード実行は、更新中の数秒だけ狙える
• 多くは寄稿者以上が必要。複数の人がログインするサイトほど、更新を急ぎたい
• 当社の保守先は翌日もまだ7.1.3。自動で上がったかは、自分で確かめる必要がある

7.0以前を使っている人はどうすればいい？

今回の修正は、セキュリティ修正を受け取れる古い版にも提供されています。公式の解説ページによると、7.0系と6.9系は22件すべての影響を受け、ほかの系列は版によって影響を受ける件数が違います。WordPress.orgでは、次の修正版が配布されています。

なお、公式ニュースでは古い版への修正を「準備中」と書いていますが、公式の解説ページと配布サイトでは、すでに公開されています（10月29日に配布ファイルを確認）。公式が「積極的にサポートしているのは最新版だけ」としている点は、これまでと同じです。古い版のままのサイトは、修正版を入れたうえで、7.1系への更新を計画してください。PHPが古くて7.0以降に上げられないサイトについては、7.1.3の記事の「WordPress 6.9.10とは？」で説明しています（考え方は6.9.11でも同じです）。

自動更新されたか確かめる方法

WordPressは、初期設定ではセキュリティの修正版（7.1.3から7.1.4のような更新）を自動で入れます。次のどれかで、更新されたかを確かめられます。

• 管理画面の「ダッシュボード」→「更新」で、現在のバージョンが7.1.4になっているか
• 管理画面の右下に表示されるバージョン
• サイトの管理者メールアドレスに、自動更新の完了メールが届いているか

自動更新を止めている、サーバーの設定で自動更新が動かない、といったサイトでは、手動で更新してください。更新前にはバックアップを取り、更新後はトップページ、記事、お問い合わせフォームなどがいつもどおり動くかを確認します。手順の考え方はWordPress 7.1.1の解説と同じです。

確かめてみて7.1.4になっていなかった、自分で更新するのが不安、という場合は、更新作業と更新後の動作確認をまとめて任せることもできます。保守サポートの内容はこちらで紹介しています。

技術者向け：WordPress 7.1.4の差分で確認したいこと

7.1.3と7.1.4の差分は、55ファイル・14コミットでした。開発者・保守担当者が確認しておきたい点です。

• 更新処理（WP_Upgrader::unpack_package）：作業フォルダ名は「パッケージ名-ランダム16文字」になり、upgrade フォルダに index.php が自動で置かれます。展開前の掃除では、upgrade フォルダの中身をindex.php 以外すべて削除します
• 本体更新の順番：展開は更新前の WP_Upgrader で行われ、そのあと新しい版の update-core.php がコピーされて読み込まれます。そのため、wp-config.php を写さない対策は7.1.4への更新時から効き、フォルダ名のランダム化は次の更新から効きます
• Interactivity API：object 要素へのバインドはグローバル属性だけに制限されました。javascript: のURLやイベントハンドラーへのバインドも修正対象です。Interactivity API を使う独自ブロックは、更新後に動作を確認してください
• ブロックの区切りの解析：PHPとJavaScriptのパーサーで、区切りの中の空白の扱いが揃えられました。保存済みの記事が想定と違う区切り方をしていないかは、念のため確認しておくと安心です
• メモ（Notes）のREST API：メモの更新・削除に、そのメモが付いた記事の編集権限が必要になりました
• ルート証明書：同梱の ca-bundle.crt が更新されました。外部APIへの接続で証明書エラーが出たときは、この変更も原因の候補に入ります

Patchstackは、更新が終わるのを待つだけでなく、サーバー側で wp-content/upgrade へのWebからのアクセスを止めることも勧めています。WordPressはこのフォルダをWeb経由ではなくサーバー上のファイルとして扱うため、止めても更新は動きます。ただし上のとおり、upgrade フォルダの中に置いた .htaccess は、次の更新の掃除で消えてしまいます。Apacheなら、たとえばサイト直下の .htaccess に次のように書きます。

Nginxなら、サーバーの設定に次のように書きます。どちらも、使っているサーバーで設定できる場所が違うため、反映後に upgrade フォルダのURLを開いて403になるか、管理画面から更新できるかを確かめてください。

よくある質問

Q. WordPress 7.1.4は今すぐ更新すべきですか？

はい。公式もすぐの更新を勧めています。いちばん重い問題は更新中の数秒だけが狙われるもので、夜中に飛び起きるほどの緊急度ではありません。ただし、寄稿者以上が条件のXSSが多く含まれるため、複数の人がログインするサイトでは今日のうちに更新を確かめてください。

Q. 自動更新が有効なら、何もしなくていいですか？

多くの場合は自動で入りますが、当社の保守先のように、公開翌日でもまだ上がっていないサイトもありました。管理画面の「更新」でバージョンを1度確かめておくと確実です。

Q. 7.1.4で見た目や機能が変わることはありますか？

7.1.4はセキュリティの修正だけで、新しい機能の追加はありません。当社の検証環境では、更新後もトップページ、ログイン画面、検索、固定ページが問題なく表示されました。Interactivity API を使ったブロックや、外部のサービスにつなぐ機能を使っている場合は、更新後に動作を確かめてください。

7.1系は2か月あまりで4回目の修正版。毎回の更新を任せませんか

7.1系は、8月19日の公開から2か月あまりで、7.1.1・7.1.2・7.1.3・7.1.4と4回の修正版が出ています。12月8日には次の大型版の7.2も予定されています。そのたびに更新されたかを確かめ、表示やお問い合わせフォームが動くかを見るのは、本業が忙しい運営者には負担です。

当社の保守サポートでは、セキュリティ更新、毎日のバックアップ（7日分）、24時間365日の監視を月額3,800円からお任せいただけます。最短1営業日で開始できます。

▶ 保守サポートの料金とプランを見る

▶ 更新後に不具合が出たときのトラブル対応

更新履歴

• 2026年10月29日：作成（公式発表と、7.1.3から7.1.4への差分を確認。当社の検証環境で更新を確認）