WordPress 7.1.4で直った13項目のセキュリティ問題｜7.1.3との差分で見る修正箇所と、自分のサイトが修正済みかの確かめ方

2026年11月8日

WordPress 7.1.4は、13項目のセキュリティ修正を含むリリース

WordPressの開発チームは2026年10月28日（米国時間）、WordPress 7.1.4を公開しました。新機能のないセキュリティリリースで、発表ではすぐに更新するよう勧めています。自動のバックグラウンド更新が有効なサイトは、自動で7.1.4へ更新されます。

直したのは、投稿や管理画面の表示にスクリプトを仕込める問題、WordPress本体の更新中に悪用されうる問題、未公開の設定が外から見える問題など13項目です。詳しい情報をまとめたHelpHubのページでは、同じ内容を22件の脆弱性として数え、それぞれ悪用にどの権限のユーザーが必要かを示しています。7.0や6.9など古い系列にも、4.7系列までの修正版が提供されています。

この記事では、修正の内訳を「悪用に必要な権限」で分け、どんなサイトほど早く更新したほうがよいかを整理します。7.1.3と7.1.4の配布ファイルを比べて、実際に変わったコードも見ていきます。最後に、自分のサイトが修正済みの版かを確かめる手順と、版を判定するスクリプトを紹介します。

修正の多くは、寄稿者以上のアカウントがあれば悪用できる問題

今回の修正の中心は、XSS（クロスサイトスクリプティング）と呼ばれる種類の問題です。投稿の本文やユーザー名などにスクリプトを仕込んでおくと、その画面を開いた別の人のブラウザでスクリプトが動きます。管理者が開けば、管理者の権限で設定を変えられるおそれがあります。

こうした問題は、スクリプトを仕込む側にも何らかの権限が必要です。HelpHubでは、各脆弱性に「寄稿者以上」「投稿者以上」「編集者以上」のように、悪用に必要な権限を書いています。WordPressの「寄稿者」は、記事を書いて下書き保存できる、いちばん下の投稿権限です。

自分ひとりで管理者として書いているブログなら、寄稿者以上が前提の問題でスクリプトを仕込めるのは自分だけです。一方、ライターや社外の人に寄稿者や投稿者のアカウントを渡しているサイト、会員登録で投稿権限を与えるサイトでは、そのアカウントの持ち主が仕込める状態でした。アカウントを乗っ取られた場合も同じです。複数人で運営しているサイトほど、自動更新を待たずに版を確かめる価値があります。ログインなしで悪用できる問題や、必要な権限が公表されていない問題も含まれるため、ひとりで運営しているサイトでも修正版への更新は必要です。

差分を見ると、表示前のエスケープと権限確認が足されている

WordPress.orgから7.1.3と7.1.4の配布zipを取得し、公式に掲載されたSHA-1の値と一致することを確かめてから中身を比べました。変わったファイルは49個で、版番号のファイルや圧縮版のJavaScriptも含みます。修正の多くは、表示する直前に文字をHTMLとして解釈させない処理（エスケープ）を足すか、操作の前に権限を確かめる条件を足すものでした。

たとえばユーザー一覧の画面では、ログイン名をそのままHTMLへ埋め込んでいた箇所が、esc_html() を通してから埋め込む形に変わっています。ログイン名にHTMLの記号が入っていても、文字として表示されるようになりました。同じ修正が、マルチサイトのユーザー一覧や上部の管理バーにも入り、プロフィール編集の画面では表示名を同じようにエスケープしています。

$edit = "<strong>{$user_object->user_login}{$super_admin}</strong><br />";

$edit = '<strong>' . esc_html( $user_object->user_login ) . "{$super_admin}</strong><br />";

権限確認の例は、カスタマイザーと、記事に付けるノートです。カスタマイザーでは、未公開の変更を自動で読み込む条件に「カスタマイズ権限を持つユーザーか」が加わりました。ノートでは、コメントを管理できる権限ではなく、そのノートが付いた記事を編集できる権限を求めるようになっています。

更新処理の修正も差分で確認できます。7.1.3では、更新ファイルを展開する作業フォルダ（wp-content/upgrade の中）の名前が、配布ファイルの名前から決まっていました。7.1.4では、名前の後ろにランダムな16文字を付け、upgrade フォルダに中身の一覧を見せないための index.php を置き、作業フォルダに wp-config.php があってもコピーしないように変わっています。作業フォルダの名前を外から推測されにくくする修正です。

同梱のルート証明書（WordPressが外部のサーバーと暗号化通信をするときに使う、信頼できる認証局の一覧）も、Mozillaの10月20日時点のデータへ更新されていました。発表はeMudhra社の証明書の信頼取り消しを更新の理由に挙げていて、同社の「emSign ECC Root CA - G3」を含む5件が外れ、4件が加わって、件数は119から118になっています。

使っている系列ごとに、修正版の番号が決まっている

WordPressは最新の7.1系列だけを正式にサポートしていますが、今回の修正は4.7系列までの古い系列にも提供されています。古い系列ほど、影響を受ける脆弱性の数は少なくなります。自分のサイトの版を、次の表の「修正版」と比べてください。

テーマ「Twenty Twenty」のファイルも修正対象に含まれています。WordPress本体の更新ではテーマのファイルは置き換わらないため、Twenty Twentyを使っている場合は「外観 > テーマ」や「更新」画面でテーマの更新も確かめてください。

自分のサイトが修正済みかを確かめる手順

確かめることは、サイトの版の数字が、使っている系列の修正版以上になっているかの1点です。管理画面に入れるなら管理画面で、サーバーのファイルを触れるならファイルで確かめられます。

1. 方法1　管理画面

   ダッシュボード > 更新 で版を見る

   画面の上部に、使用中のWordPressの版の数字が表示される。修正版より古ければ、同じ画面から最新版へ更新できる。

2. 方法2　サーバーのファイル

   wp-includes/version.php の $wp_version を見る

   WP-CLIが使えるなら wp core version でも同じ数字が出る。複数のサイトを管理しているときに向く。

3. 方法3　判定スクリプト

   系列ごとの修正版と自動で比べる

   古い系列を含む複数のサイトがあるときは、下のスクリプトで版を読み取り、修正版より古いかを判定できる。

方法3のスクリプトは、WordPressを置いたフォルダ（wp-includes フォルダがある場所。レンタルサーバーなら public_html の中など）を渡すと、version.php から版を読み、表の修正版と比べて結果を表示します。WordPressやPHPは動かさず、ファイルを読むだけです。下の内容を check-wp-fixed.sh という名前で保存し、SSHでサーバーに入って sh check-wp-fixed.sh の後ろにそのフォルダの場所を付けて実行します。管理画面だけで確かめる場合は、方法1で足ります。

#!/bin/sh
# WordPressの wp-includes/version.php を読み、2026年10月28日のセキュリティ修正を含む版かを判定する。
# 使い方: sh check-wp-fixed.sh /path/to/wordpress（wp-includes フォルダがある場所）
dir="${1:-.}"
file="$dir/wp-includes/version.php"
if [ ! -f "$file" ]; then
  echo "見つかりません: $file"; exit 2
fi
ver=$(tr -d '\r' < "$file" | sed -n "s/^\$wp_version = '\([^']*\)';.*/\1/p")
if [ -z "$ver" ]; then
  echo "版を読み取れません: $file"; exit 2
fi
base=${ver%%-*}   # 7.2-beta3-61234 のような開発版の後ろを外す
major=$(echo "$base" | cut -d. -f1)
minor=$(echo "$base" | cut -d. -f2)
patch=$(echo "$base" | cut -d. -f3); patch=${patch:-0}
case "$major.$minor.$patch" in *[!0-9.]*|.*|*..*) echo "版を読み取れません: $ver"; exit 2;; esac
branch="$major.$minor"
# 7.3 以降は、10月28日の修正を含んで出る
if [ "$major" -gt 7 ] || { [ "$major" -eq 7 ] && [ "$minor" -ge 3 ]; }; then
  echo "$ver: 10月28日より後の系列です"; exit 0
fi
if [ "$branch" = "7.2" ]; then
  case "$ver" in
    *alpha*|*beta1*|*beta2*|*beta-1*|*beta-2*)
      echo "$ver: 7.2の開発版で、修正前です。7.2 Beta 3 以降か 7.1.4 にしてください"; exit 1;;
    *) echo "$ver: 7.2 Beta 3 以降で、修正を含みます"; exit 0;;
  esac
fi
case "$branch" in
  7.1) need=4;; 7.0) need=8;; 6.9) need=11;; 6.8) need=12;; 6.7) need=11;; 6.6) need=11;;
  6.5) need=14;; 6.4) need=14;; 6.3) need=14;; 6.2) need=15;; 6.1) need=16;; 6.0) need=18;;
  5.9) need=20;; 5.8) need=19;; 5.7) need=21;; 5.6) need=23;; 5.5) need=24;; 5.4) need=25;;
  5.3) need=27;; 5.2) need=30;; 5.1) need=28;; 5.0) need=31;; 4.9) need=35;; 4.8) need=34;; 4.7) need=39;;
  *) echo "$ver: この系列にはセキュリティ修正が提供されていません。最新版へ更新してください"; exit 1;;
esac
if [ "$patch" -ge "$need" ]; then
  echo "$ver: 10月28日の修正を含みます（$branch 系列は $branch.$need 以降）"; exit 0
else
  echo "$ver: 修正前です。$branch.$need 以降へ更新してください"; exit 1
fi

7.1.3と7.1.4の配布ファイルと、版番号だけを書き換えた見本12件で試した結果の一部は次のとおりです。修正前の版では更新先の版を示して終了コード1を、版を読み取れないときは終了コード2を返すので、複数のサイトをまとめて調べるスクリプトにも組み込めます。

$ sh check-wp-fixed.sh src/7.1.3/wordpress
7.1.3: 修正前です。7.1.4 以降へ更新してください
$ sh check-wp-fixed.sh src/7.1.4/wordpress
7.1.4: 10月28日の修正を含みます（7.1 系列は 7.1.4 以降）
$ sh check-wp-fixed.sh sample/6.9.10
6.9.10: 修正前です。6.9.11 以降へ更新してください
$ sh check-wp-fixed.sh sample/7.2-beta2
7.2-beta2-61100: 7.2の開発版で、修正前です。7.2 Beta 3 以降か 7.1.4 にしてください
$ sh check-wp-fixed.sh sample/4.6.30
4.6.30: この系列にはセキュリティ修正が提供されていません。最新版へ更新してください

自動更新が有効なら、多くのサイトはすでに修正版になっているはずです。ただ、自動更新を止めているサイトや、サーバーの書き込み権限の都合で更新に失敗しているサイトもあります。運営しているサイトの版の数字を、今日のうちに一度確かめておくのがおすすめです。複数人で投稿するサイトでは、特に早めに確かめてください。