制作会社に保守を任せているコーポレートサイトで、管理画面のフッターに「7.1.2」への更新案内が出ている。自社の版は7.0系のまま。9月にWordPressのセキュリティ修正が2回出て、CloudflareもWordPress向けのWAFルールを緊急で追加したと聞いた——このサイトは修正済みなのか、それとも取り残されているのか。
結論から言うと、最新の7.1.2でなくても、使っている系列の修正版になっていれば9月の修正は入っています。逆に、設定や構成によってはコアの自動更新は動きません。WordPress本体の公開リポジトリ（wordpress-develop）のタグとコードを編集部が直接読み、修正済みの版、直った内容、自動更新が止まる条件、確認の手順を整理します。
9月に出た2回の修正と、系列ごとの「修正済みの版」
wordpress-develop のタグの日付（UTC）で見ると、修正は2段階で出ています。
- 2026年9月17日: 7.1.1。 権限の確認や出力処理の修正11件が入りました。同日、古い系列にも「Security: Backport the WordPress 7.1.1 security fixes to the 7.0 branch.」のようなコミットで、7.1.1の修正が「security fixes」として移植されています
- 2026年9月22日: 7.1.2。 「Themes: Restrict path traversal in
locate_template().」の1件だけを含む版です。同じ修正が古い系列にも同日に入りました
自動更新は、基本的に同じ系列の中で版を上げます（後述）。そのため確認すべきなのは「最新の版か」ではなく、「自社の系列で、9月22日の版以上か」です。
| 使っている系列 | 9月17日の修正版 | 9月22日の修正版（ここ以上なら両方入っている） |
|---|---|---|
| 7.1 | 7.1.1 | 7.1.2 |
| 7.0 | 7.0.5 | 7.0.6 |
| 6.9 | 6.9.8 | 6.9.9 |
| 6.8 | 6.8.9 | 6.8.10 |
| 6.7 | 6.7.8 | 6.7.9 |
| 6.6 | 6.6.8 | 6.6.9 |
| 6.5 | 6.5.11 | 6.5.12 |
6.4〜4.7の各系列にも9月17日と22日のタグがあり、両方の修正が移植されています（例: 6.4.12、6.0.16、5.9.18、4.7.37）。古い系列への移植は一部のことがあり、4.7系の移植コミットは11件中6件を列挙しています。4.6以前の系列には2026年9月のタグがありません。WordPress.orgのリリース告知は編集部の環境から開けなかったため、告知の文面は扱っていません。
何が直ったのか（サイト運営者向けの粒度）
9月22日: テンプレートを探す関数が、テーマの外を読まないようにした
locate_template() は、テーマの中からテンプレートファイルを探す関数です。7.1.2では、名前に .. を含む場合、実際の置き場所がテーマか本体の theme-compat ディレクトリの中にあるときだけ読み込む確認（_wp_is_template_path_allowed()）が加わりました。固定ページのテンプレートを決める get_page_template() にも、URLデコードしたページ名を validate_file() で検査する変更が入っています。
編集部の検証環境（Linux、PHP 8.3.6）で、7.1.1と7.1.2の template.php を最小限の代替関数と読み込み、locate_template() を呼びました。テーマ内のファイルは両方の版で見つかり、テーマの外の無害なダミーファイルを指す名前は、7.1.1ではパスが返り、7.1.2では空文字（見つからない扱い）になりました。関数の差を確かめただけで、実サイトへの影響は検証していません。
9月17日: 権限の確認と出力の処理
7.1.1の11件を、コミットの見出しと差分から分けると次のとおりです。
- 権限の確認。 パーマリンクを作るAjax処理、メディア編集画面での添付先の投稿の表示、REST APIでのノート（コメント）の付け先の変更、XML-RPCからの内部用の投稿タイプへの書き込み、ネットワーク専用プラグインのAjaxでの有効化など
- 出力・入力の処理。
wpautop()とblockquoteの属性、HTML APIのコメント、テーマのインストール画面のURL由来の値、カスタマイザーのヘッダー画像の値 - ブロックテーマのテンプレートファイルの解決を、テンプレート用ディレクトリの中に限定
GitHubのAdvisory Databaseには、NVD由来の未レビューの記録として CVE-2026-93485（WordPress本体のクロスサイトスクリプティング）があり、影響範囲は「7.1 before 7.1.1; 7.0 through 7.0.4; …; 4.7 through 4.7.35」と、9月17日の修正版の直前までが並んでいます。どのコミットに当たるかは特定できませんでした。
「自動更新のはず」が当てにならない理由
7.1.2のコード（class-core-upgrader.php の should_update_to_version()）では、本体の自動更新を次のように判定します。
- 同じ系列の中の更新（7.1.1→7.1.2、6.8.9→6.8.10）は、設定を保存していなければ既定で許可
- 系列をまたぐ更新（7.0.6→7.1.2）は、既定では許可しない
編集部の検証環境でこの関数を代替関数と実行すると、上の3組は「更新する」「更新する」「更新しない」となり、WP_AUTO_UPDATE_CORE を false にすると6.8.9→6.8.10も「更新しない」になりました（設定を保存していない状態）。更新画面で全バージョンの自動更新（Enable automatic updates for all new versions of WordPress.）を選んだサイトや、WP_AUTO_UPDATE_CORE が true のサイトでは、系列をまたぐ更新も許可されます。
図は7.1.2のコードを編集部が読んで整理したもので、管理画面の画面ではありません。上から順に、どこか1つでも当てはまるとコアの自動更新は行われません。
| 条件（コードの該当箇所） | 結果 |
|---|---|
DISALLOW_FILE_MODS か AUTOMATIC_UPDATER_DISABLED が true、または automatic_updater_disabled フィルター | 自動更新の全体が止まる |
ファイルを書き込めない（FTPの資格情報を求められる）、または本体の場所やその上の階層に .git .svn .hg .bzr がある | コアは更新せず、配信側の指定があれば管理者へメール |
WP_AUTO_UPDATE_CORE が false、または allow_minor_auto_core_updates フィルターで false | 同じ系列の修正版も入らない |
| 以前の自動更新が重大な失敗（critical）で終わった記録がある | 以後の自動更新を試みない |
自動更新は、WP-Cronで1日2回走る更新確認から起動します。DISABLE_WP_CRON が true だとページ表示でcronが起動しないため、サーバー側でcronを回していなければ更新確認も走らない、と編集部はコードから読んでいます（実サーバーでは未検証）。
制作会社がGitでサイトを管理している場合は、バージョン管理の検出で自動更新が止まります。コードのコメントにあるとおり「バージョン管理しているなら更新はその運用で決める」という前提で、不具合ではありません。
確認の手順と、制作会社への聞き方
管理者アカウントで、次の順に確認します（画面の文言は英語の原文で示します。日本語版での表記は未確認です）。
- 今の版を見る。 左メニューの「Updates」（
/wp-admin/update-core.php）の画面に「Current version: 〜」として今の版が出ます。フッター右側は、更新があると今の版ではなく「Get Version 7.1.2」のような案内に変わります - 上の表と照らす。 自社の系列の「9月22日の修正版」以上なら、9月の2回の修正は入っています
- 自動更新の状態を見る。 同じ画面に自動更新の状態が1文で出ます。「This site appears to be under version control.」なら、バージョン管理の検出で止まっています
- サイトヘルスを見る。 「Tools」の下の「Site Health」（
/wp-admin/site-health.php）にある「Background updates」の検査は、上の表の定数・フィルター・バージョン管理・書き込み権限・過去の失敗をまとめて調べます
保守を外注しているなら、制作会社には次のように聞くと答えがぶれません（編集部の提案）。
- 本体の今の版と、9月22日付の修正版（自社の系列の版）を当てた日
- コアの自動更新が有効か。止めているなら理由（Git運用・定数・プラグイン）と、手動で当てる手順と頻度
- 独自テーマやプラグインで、URLやフォームの値を
locate_template()やget_template_part()などのテンプレート読み込みに渡している箇所がないか。本体の修正はlocate_template()自体を守りますが、テーマやプラグインが独自にファイルを読み込む処理までは対象外です
本体の更新が放置されがちな理由と体制の作り方はWordPress本体の緊急脆弱性「wp2shell」の記事で、運営体制を見るときの観点は「WordPressは大丈夫なんですか」と聞かれたときの答え方で扱いました。
CloudflareのWAFルールは「つなぎ」として扱う
Cloudflareは2026年9月25日の緊急リリースで、Cloudflare Managed Rulesetに「Wordpress - Path Traversal, Local File Inclusion - CVE:CVE-2026-87902」と「Wordpress - XSS - Comment」の2つのルールを新規に追加しました（動作はBlock）。告知はCVE-2026-87902を、未認証でサーバー上の任意のファイルを読まれうる高深刻度の脆弱性と説明し、最新のパッチの適用を強く勧めています。
このCVE-2026-87902が9月22日の locate_template() の修正と同じものかは、未確認です。告知は対象の版やコミットを示さず、wordpress-develop のコミットにもCVE番号はなく、GitHub Advisory Databaseにも記録が見当たりませんでした。種類が近いことだけで同一視はしません。「Wordpress - XSS - Comment」とCVE-2026-93485の関係も同様に未確認です。
WAFは既知の攻撃パターンを入口で止める仕組みで、本体の修正の代わりにはなりません。Managed Rulesetを使っているサイトでも、版の確認と更新は別に行います（プランごとの提供範囲は未確認）。
2026年10月1日に、WordPress本体の公開リポジトリ（wordpress-develop）で7.1.1・7.1.2と4.7〜7.0系列のタグ・コミット・差分、7.1.2の自動更新のコードを直接読み、CloudflareのWAFの告知（2026年9月25日）をドキュメントのソースリポジトリで、CVE-2026-93485の記録をGitHub Advisory Databaseで確認しました。WordPress.orgの告知は遮断のため未読です。PHPでの確認は本体の関数を最小限の代替関数と動かしたもので、WordPressのインストール、実サイトの更新、WAFの動作は検証していません。
WordPressサイトの更新状況の確認や保守体制の見直しは、Webサイト制作・保守のご相談からお問い合わせください。
Sources
- Themes: Restrict path traversal in
locate_template()（7.1ブランチ） — WordPress/wordpress-develop - Tag 7.1.2 — WordPress/wordpress-develop
- Tag 7.1.1 — WordPress/wordpress-develop
- Security: Backport the WordPress 7.1.1 security fixes to the 7.0 branch — WordPress/wordpress-develop
- Security: Backport the WordPress 7.1.1 security fixes to the 4.7 branch — WordPress/wordpress-develop
- class-core-upgrader.php（7.1.2） — WordPress/wordpress-develop
- class-wp-automatic-updater.php（7.1.2） — WordPress/wordpress-develop
- WAF Release - 2026-09-25 - Emergency — Cloudflare Changelog
- GHSA-2pgq-4jch-68j8（CVE-2026-93485） — GitHub Advisory Database
