WordPress 7.1.4の脆弱性と更新内容｜更新中のRCEで直った3点と、証明書更新の意味

2026.10.30

グレープフルーツ編集部

22日で、また「直ちに」が来ました。10月29日、WordPressの日本語公式サイトに7.1.4の告知が出ています。英語版は前日の28日。7.1.3が出たのが10月6日なので、22日しか空いていません。

グレープフルーツ編集部です。7.1.3のときは告知を読めば修正の中身がだいたい分かったのですが、今回は1行ずつ読んでも分かりませんでした。

なので、英語版、詳細版のHelpHub、GitHubにある7.1.3と7.1.4の差分まで追っています。

先に答えると、7.1.4はセキュリティ修正だけのリリースで、文言は今回も「直ちに」。目玉は「更新している最中に乗っ取られる」穴と、見慣れない「ルート証明書の更新」という項目です。

13項目と22件、どちらが正しいのか

同じ修正の束を13項目と22件の二つの単位で数え分けている図

公式告知に並んでいるのは13項目。「直った問題」の欄は日本語公式訳をもとに表にします（表記はこの記事の書式に揃え、報告者は要約）。

番号	直った問題	報告者
1	WordPressのアップグレード処理における脆弱性で、アップグレードの実行中にリモートコード実行につながるおそれがある問題	Umut Bayram
2	細工されたブロックマークアップによる格納型XSSの問題	Rafie Muhammad（Awesome Motive, Inc.）
3	個人データの消去リクエストが、格納型XSSにつながる形で作成できてしまう問題	Anthropic
4	Interactivity APIにおける複数の格納型XSSの問題	VietSunshine Cyber SecurityのAnCとDatNLQほか、複数の報告者がそれぞれ独立して発見
5	Interactivity APIにおける格納型のサービス拒否の問題	WordPressセキュリティチームのJon Surrell
6	カスタマイザーの選択的リフレッシュにおける格納型XSSの問題	Rafie Muhammad（Awesome Motive, Inc.）
7	カテゴリーブロックにおける格納型XSSの問題	WordPressセキュリティチームのBen Bidner
8	細工されたユーザー名によって格納型XSSが発生する可能性がある問題	Anthropic
9	公開されていないカスタマイザーの変更セットを、未認証のユーザーが発見できる問題	Antonio Lorensius Silaban
10	プレイリストブロックと画像ブロックにおける格納型XSSの問題	WordPressセキュリティチームのBen Bidner
11	core/comments-pagination-nextブロックとcore/comments-pagination-previousブロックにおける格納型XSSの問題	WordPressセキュリティチームのAlex Concha
12	ノートが付けられた投稿の編集権限を持たない特権ユーザーが、そのノートを閲覧できる問題	WordPressセキュリティチームのRamon
13	eMudhraの失効に伴う、同梱のルート証明書の更新	—

数えると13。ただ、これを「13件の脆弱性」と呼ぶのは少し違うかと思います。13番目は脆弱性ではなく、証明書の束を入れ替えた話なので、正確には脆弱性に関する項目が12、証明書の更新が1です。

ここまでは告知を読めば分かります。

ややこしいのは、公式の詳細版であるHelpHubのほうです。そちらは項目が18に増え、旧バージョンへの影響を書いた段落には「22 vulnerabilities」とあります。

増えた理由は、主に4番目。

告知で「Interactivity APIにおける複数の格納型XSS」と1行にまとめられたものが、HelpHubでは複数の項目に分かれていました。逆に、告知の4番目と5番目（XSSとサービス拒否）を1項目にまとめた行もあって、差し引きで18。18項目のうち17が脆弱性で、それを個別の問題として数えると22件になる、という数え方です。どの項目が複数件扱いなのか、内訳は公式に書かれていないので、ここから先は数えようがありませんでした。

つまり13も22も間違いではなく、数えている単位が違うだけ。この記事では告知の番号で呼びます。

報告者の欄を見ると、今回もAnthropicの名前が2件。前回は3件でした。もう珍しくなくなってきましたね。

それと、10月30日時点ではどの項目にもCVE番号が付いていません。番号で検索しても出てこないのはそのためです。

更新中のRCEで直った3点

1番目の項目は、公式の説明が1行しかありません。HelpHubでも「コア更新中の競合状態で、リモートコード実行につながる可能性がある」まで。どういう条件で成立するのかは、告知にもHelpHubにも書かれていませんでした。

正直、ここが一番時間を使ったところです。

セキュリティ会社Patchstackの解説記事には、もう少し具体的に書いてあります。

WordPressは本体を更新するとき、新しいファイル一式をwp-content/upgrade/の下に展開してから、本番の場所へコピーします。その展開先のフォルダ名が、管理画面から入れた更新なら完全に推測できて、しかもWebから届く場所にあった。展開中の数秒間だけ、その中のsetup-config.phpが外から開ける状態になる、という問題でした。

同社の脆弱性データベースでの評価は、CVSSが9、対応の優先度は「Low」。点数は危険度の最上位クラスなのに優先度は低くて、「実際に悪用するのは現実的でない」とも書いてあります。更新が走っている数秒に当てる必要があるからです。

数字だけ見ると怖いし、条件を読むと「そうそう当たらない」とも思える……。

で、何が直ったのか。GitHubで7.1.3と7.1.4のファイルを並べて見比べると、修正は3点に絞れました。

// wp-admin/includes/class-wp-upgrader.php
'-' . wp_generate_password( 16, false )

// wp-admin/includes/update-core.php
// Never copy a wp-config.php

1点目は、作業フォルダの名前です。これまで予測できた名前の末尾に、16文字のランダムな文字列が付くようになりました。名前が当てられなければ、外から狙いようがありません。

2点目は、展開先の親にあたるwp-content/upgrade/にindex.phpを置くこと。中身は「Silence is golden」というコメントだけの、WordPressではおなじみのファイルです。これまでは更新前の掃除でこのファイルごと消していたので、フォルダの一覧から展開先の名前を見つけられる余地がありました。7.1.4では掃除のときも残します。

3点目は、コピー対象からwp-config.phpを外したこと。コメントには「Never copy a wp-config.php」とあり、作業フォルダにwp-config.phpが紛れ込んでいても、それを本番の場所へ持ち込まない、という念押しです。

wp-content/upgrade/にWebから届く構成なら、更新のたびにこの数秒の窓が開いていたことになります。

ひとつ注意があって、1点目と2点目は展開を担当する側、つまり更新前のバージョンのコードで動きます。効くのは7.1.4を当てた後、次の更新から。3点目は新しいパッケージ側のコードなので、今回の更新から効きます。ちなみにこの版では、データベースのスキーマ番号に変更がありません。

私が確認した範囲では、この脆弱性で侵害されたサイトの報告は今のところ見つけていません。

Interactivity APIはどこで動くのか

HelpHubの17項目のうち、7項目がInteractivity API絡みでした。半分近くです。

名前だけ見ると開発者向けの話に見えますよね。私も最初はそう思いました。

Interactivity APIは、ブロックに「クリックで開く」「状態に応じて表示を切り替える」といった、公開ページ側の動きを付けるための標準の仕組みです。HTMLにdata-wp-onやdata-wp-bindのような属性を書き、JavaScript側で状態を定義します。

6.4で非公開のAPIとしてコアのブロックが先に書き換えられ、6.5で公開APIになりました。

問題は、これがどこで動いているか。

公式ドキュメントで確認できる範囲だと、次の場所です。

画像ブロックの「クリックで拡大」（ライトボックス）
ナビゲーションブロックのモバイルメニューの開閉
クエリループで「Reload Full Page」を切ったときのページ送り
展開型の検索ブロック、ファイルブロック

画像をクリックすると拡大表示される、あれです。記事一覧のページを送るときに画面全体が切り替わらず、一覧だけが差し替わるサイトもそうです。

7項目のうち6つは、寄稿者以上（1件は投稿者以上）の権限を前提にした問題で、多くは格納型XSSでした。残る1つは権限の記載がありません。ログインしていない人が外から直接突ける穴とは違って、裏返すと、外部ライターや複数の担当者に寄稿者権限を渡しているサイトほど関係が深い。

使っていないブロックなら無関係、とは言い切れないところが面倒で……。更新を当てるほうが早い、が私の結論です。

証明書の更新はサイトのSSLとは別物

13番目の「eMudhraの失効に伴う、同梱のルート証明書の更新」。告知を読んだとき、一瞬「うちのサイトのSSLに何かあるのか」と思いました。

別物でした。

eMudhraはインドの認証局で、「emSign」というブランドでルート証明書を運用しています。

10月17日に中間CAの秘密鍵が弱いという報告が上がり、翌18日に8枚の中間CAが失効。Chromeは10月27日にルート証明書「emSign ECC Root CA – G3」を自社のルートストアから外すと告知し、Mozillaも10月20日のNSS 3.131.1でemSignのルートを削除しています。

ブラウザ側の対応は、こうしてすでに進んでいました。

ではWordPressは何を更新したのか。

WordPressはwp-includes/certificates/ca-bundle.crtというファイルに、信頼するルート証明書の束を同梱しています。使う場面はWordPressが外へ出ていく通信。wordpress.orgへの更新確認、プラグインやテーマのダウンロード、外部APIとの連携で、相手のサーバーが本物か確かめるときです。

サイト自身のSSL証明書を交換する更新ではありません。訪問者がブラウザでサイトを開くときは、サイトのSSL証明書と、訪問者のブラウザが持つルートで検証されます。

差分を見ると、7.1.3の束は119枚、7.1.4は118枚。

emSign系3枚を含む5枚が消え、4枚が足されています。足された4枚のうち2枚は「SECOM TLS ECC Root CA 2024」と「SECOM TLS RSA Root CA 2024」で、日本の読者には馴染みのある名前かと思います。残り2枚はTelia。元になっているMozillaのCAリストの日付も、7月16日から10月20日に進んでいました。

消えたルートから発行された証明書を持つサーバーには、7.1.4のWordPressから接続すると検証で弾かれる。影響があるとすれば、その向きです。逆に「7.1.4を当てないとサイトが表示されなくなる」は起きません。

7月から7回目のセキュリティリリース

7.1.4は、7.1系では4回目、7月以降では7回目のセキュリティリリースです。

バージョン	公開日
7.0.2	2026-07-17
7.0.3	2026-08-06
7.0.4	2026-08-12
7.1.1	2026-09-17
7.1.2	2026-09-22
7.1.3	2026-10-06
7.1.4	2026-10-28

7.1の公開が8月19日なので、70日で4回。間隔は最短で5日、今回は22日でした。

月に1、2回のペースです。

7.1.3の記事で「慣れそうになる」と書きましたが、慣れている暇がないですね。修正は4.7まで順次さかのぼって配布され、7.0系には同じ日に7.0.8が出ています。

バージョンの分布も動きました。10月30日時点の公式統計では、7.1系が64.6%。7.1.3の記事を書いた10月15日は61.8%だったので、半月で2.8ポイント増えています。公式の統計は日々動くので、目安として。

PHPは7.4がまだ14.9%。前回の16.3%から減ってはいますが、7サイトに1つはサポートの切れたPHPで動いている計算です。7.1.4の動作要件はPHP 7.4以上、MySQL 5.5.5以上で据え置きですが、「動く」と「安全」が別なのは前回書いたとおり。なお、この統計はwordpress.orgに更新確認をしに来たサイトの比率なので、日本だけ切り出すと違う数字かもしれません。

古いPHPで動き続けているサイトは、たいていデザインも当時のままです。更新と一緒に見直すなら、こちらも。

古いホームページをデザイン改善して集客につなげる方法

古いホームページ、使っていませんか？デザイン改善で集客に差をつける秘訣「うちのホームページ、なんだか古くてダサいかも…」そう感じている中小企業の経営者やウェブ担当者の方、多いのではないでしょうか。せっかく時間とお金をかけて作っ…

次の7.2は12月8日予定のまま動いていません。Beta 3が7.1.4と同じ日に出て、該当する修正は全部入っています。「どうせ12月に7.2が来るなら、7.1.4は飛ばして待つ」は、41日間穴を開けたままにする選択なので、やめたほうがいいです。

更新後に見ておきたい3か所

更新の手順と自動更新の仕組み、更新前に確認することは前回の記事にまとめてあるので、今回は繰り返しません。

WordPress 7.1.3の更新内容と修正7件の中身

WordPress 7.1.3の更新内容と修正7件の中身 WordPress 7.1.3（2026年10月公開）のセキュリティ修正7件とバグ修正4件を公式告知をもとに整理。承認待ちコメント経由のXSSなど気になる中身、7.1.1〜7.1.2からの流れ、更新の手順と更新前に確認する4点をWeb制作会社がまとめます。

7.1.4で私が見ているのは、この3か所です。

7.1.4で見ておく3か所

管理画面の「更新」でバージョンが7.1.4になっているか
「ユーザー」一覧で、寄稿者・投稿者・編集者が誰になっているか
レンタルサーバーからの告知メールやお知らせ

1つ目は、自動更新が有効なサイトでも見ます。更新が走ったかどうかは、数字を見るまで分からないので。

2つ目は、Interactivity APIの7項目のほとんどが寄稿者以上の権限を前提にしていたからです。辞めた外部ライターのアカウント、残っていないでしょうか。更新とは別に、ここを棚卸しする機会にしてもいいかもしれません。

3つ目は、告知の出し方や自動更新の扱いが事業者によって違うからです。自分のサーバーのお知らせは一度見ておくと安心です。

更新を当てた後に、公開ページを一通り見て回るのは7.1.3のときと同じです。

正直、22日でまた「直ちに」が来るとは思っていませんでした。でも今回の差分を追ってみて、更新処理そのものを守る修正が入ったのは、私には納得のいく理由でした。更新を安全にするための更新、というのは少し皮肉ですが。

誰が更新しているのか分からない、保守契約に入っているのか分からない。そういう状態ならお問い合わせから聞いてもらって構いません。ただ「今の制作会社がちゃんとやっています」という答えになることも多いはずで、そのときはそう言います。

参考・出典

ナレッジホームページ制作

WordPress 7.1.3の更新内容と修正7件の中身

Written by