WordPress の脆弱性 CVE-2026-87902：自分のサイトは直っている？確かめ方と上げる版

2026年9月22日、WordPress の本体にある「critical（重大）」とされた脆弱性を直した版（画面では「バージョン」と出ます）、WordPress 7.1.2 が出ました。脆弱性とは、悪用されると困ることが起きうる、ソフトウェアの弱点のことです。告知は、条件がそろうと、ログインなしで、外から機械を好きに動かされる恐れがあると書いています。ここでの「機械」は、WordPress が動いているサーバー、つまりサイトを置いてあるコンピューターのことです。専門の言葉では「リモートコード実行」、略して RCE と呼びます。

先に答えを書きます。

確かめ方： 管理画面の「ダッシュボード」→「更新」を開き、「現在のバージョン」を見ます。7.1 系なら 7.1.3 以上か（7.0 系は 7.0.7、6.9 系は 6.9.10。ほかは版の表）。系統は、版の頭の2つの数字です（7.1.3 なら 7.1）
足りなければ： 同じ画面の「バージョン ○○ に更新」を押します。上げる先は、更新の画面が出す版で構いません
7.1.2 では足りない理由： この件は、9月22日の版（7.1 系は 7.1.2、7.0 系は 7.0.6、6.9 系は 6.9.9 のように、4.7 系まで）で直りました。ただ、10月6日に 7.1.3 が出ていて、WordPress.org の公開の API（プログラムが問い合わせる仕組み）は 7.1.2 を「insecure」と返します（2026年10月22日 17時24分ごろ）。7.1.3 には、この件とは別の7件のセキュリティの直しが入っています
悪用： CISA（アメリカの政府機関）が、9月25日に KEV（悪用が確認された脆弱性の一覧）に加えました。WordPress.org の告知は、悪用には触れていません
自動更新： WordPress の保守とセキュリティの更新は、ほとんどのサイトで、最初から自動で上がる設定です。ただし、上がらない場合があります。上がったかは、「現在のバージョン」で見ます
PHP は別： 10月21日の PHP の脆弱性とは、上げる物が別です。WordPress.org は、PHP の件のために WordPress を更新する必要はないと書いています。PHP の方は、PHP の脆弱性の記事に書きました

この記事は、WordPress でブログやサイトを動かしている人、特にレンタルサーバーで動かしている人に向けて、「何があった → 自分のは直っているか → 自動で上がらないのはどんなときか → 悪用の状況 → レンタルサーバーの人は → 入られたかもしれないとき → 資料によって違って見えるところ」の順に書きました。書いてあることは、WordPress.org の告知、GitHub（プログラムのソースコードを置いて、みんなで開発するサービス）の告知、CVE の記録、CISA の KEV、JPCERT/CC（日本のセキュリティの情報を扱う組織）、IPA（情報処理推進機構）の文書などを、2026年10月22日に開いて確かめたもので（悪用の状況や新しい版は日々変わります）、脆弱性を突く操作はしていません。

この記事でわかること

9月22日に出た件は何か（条件がそろうと、外から機械を好きに動かされる恐れ）
直った版（系統ごと）と、いま上げる先。7.1.2 に上げただけでは足りない理由
管理画面での確かめ方（「ダッシュボード」→「更新」の「現在のバージョン」）
自動で上がらないのは、どんなときか。止めるのを強く勧めない、という公式の言葉。上がったかの見分け方
悪用は確認されているか（2026年10月22日時点）。レンタルサーバーの人が見ること。入られたかもしれないときの案内
点数や呼び名が、資料によって違って見えるところ

WordPress に、9月22日に何があった？
自分の WordPress は直っている？どう確かめる？
自動で上がらないのは、どんなとき？
悪用はされている？（2026年10月22日時点）
レンタルサーバーで WordPress を動かしている人は？
1. PHP の10月21日の件とは、別の話です
2. 本体のほかに、テーマとプラグイン
入られたかもしれないときは？
資料によって違って見えるところ（ほかの資料と見比べる人へ）
よくある質問
まとめ
参考資料

WordPress に、9月22日に何があった？

WordPress.org は、2026年9月22日に WordPress 7.1.2 を出しました。告知の本文は、これは「critical severity（重大度が critical）の脆弱性」1件の直しを入れたセキュリティの版だと書き、次のように、すぐ更新するよう勧めています。

"Because this is a security release, it is recommended that you update your sites immediately."

訳すと、「セキュリティの版なので、すぐ更新することを勧める」です。更新の方法は、管理画面の「Dashboard」の「Updates」から「Update Now」を押す、と書いています。また、自動のバックグラウンド更新（人が操作しなくても、WordPress が裏で更新する仕組み）に対応したサイトでは、更新が自動で始まる、とも書いています。

たとえ話で、壊れている場所を見ます。ここでの「テンプレート」は、ページの見た目のひな形、「テーマ」は、サイトの見た目を決める部品のことです。

役所の窓口に、お客さんに渡す書類の「ひな形」を取りに行く係がいます。決まりでは、ひな形は「この窓口の棚」から取ってきます。ところが、ある条件がそろうと、この係が、棚の外にある別の書類を、ひな形だと思って持ってきてしまいます。ただし、いつでも起きるわけではありません。棚の形と、建物の中にある物の、両方の条件がそろったときだけです。壊れているのは、この「棚の外の書類を、ひな形として持ってきてしまう」ところです。直したのは、この係のほうです（棚の外へ取りに行けないようにしました）。

本当の説明では、こうなります。告知の原文の、該当の部分です。

"…an unauthenticated attacker can, under certain conditions, make page template resolution include a chosen readable local PHP file outside the active theme directories. If relevant pre-conditions for both the server environment and the active theme are met, this can lead to remote code execution (RCE)."

訳すと、こうです。認証なし（ログインしていない）の攻撃者が、ある条件のもとで、ページのテンプレートを決める処理に、有効なテーマのフォルダーの外にある、読める、攻撃者が選んだローカル（サーバーの上）の PHP のファイルを読み込ませられます。サーバーの環境と、有効なテーマの、両方について関係する前提条件がそろうと、遠隔のコード実行（RCE）につながりえます。

たとえ話の「窓口の棚」は、いま使っているテーマのフォルダー、「係」は、ページのテンプレートを決める処理、「棚の外の書類」は、テーマのフォルダーの外にある、読める PHP のファイルに当たります。「棚の形と、建物の中にある物」は、テーマとサーバーの条件です。この条件がそろうと、外から機械を好きに動かされる恐れがある、というのが告知の書き方です。条件の細かい中身は、この記事では書きません。読む人がやることは、自分が条件に当たるかを調べることではなく、直った版に上げることだからです。

直しは、WordPress の本体の側に入っています。直しのコミット（変更の記録）の題は "Themes: Restrict path traversal in locate_template()." で、テーマのテンプレートを探す処理で、フォルダーの外へ出る指定（パストラバーサル）を制限した、という意味です。

告知は、この件の番号を名指ししています。CVE 番号は、脆弱性に付ける世界共通の番号です。GHSA は、GitHub の告知につく番号です。


CVE 番号	CVE-2026-87902
GitHub の告知の番号	GHSA-7hp8-65ch-5whp
告知の重大度	critical

出典: WordPress 7.1.2 の告知・GitHub の告知（GHSA-7hp8-65ch-5whp）・CVE の記録

自分の WordPress は直っている？どう確かめる？

先に、やることを書きます。管理画面で今の版を見て、下の表の自分の系統の「いま上げる先」と比べます。それより前の版なら、上げます。直し方として、WordPress.org の告知も、GitHub の告知も、JPCERT/CC の紹介も書いているのは、「直った版に更新する」ことだけです。テーマを替える、ファイルを消す、といった暫定の手立ては、この記事で読んだ文書には書かれていません。

管理画面で、いまの版を見る

管理画面にログインして、左のメニューの「ダッシュボード」→「更新」を開きます（メニューの「更新」の横に、待っている更新の数の丸が付くことがあります）。画面の題は「WordPress の更新」です。画面の上のほうに、次のような文字が出ます。

画面の文字	意味
現在のバージョン: 7.1.3	いま入っている版。ここを見ます
最終チェック日時: … ／再確認してください。	最後に新しい版を確かめた日時。古いときは「再確認してください。」のリンクを押します
最新バージョンの WordPress をお使いです。	待っている新しい版は無い
バージョン ○○ に更新	新しい版がある。このボタンで上げます

ほかにも、版が出る場所があります。ダッシュボードの「概要」の箱の下に、「WordPress 7.1.3 (○○ テーマ)」の形で出ます。「ツール」→「サイトヘルス」→「情報」→「WordPress」の「バージョン」の行でも見られ、新しい版があるときは、後ろに「(最新バージョン: ○○)」が付きます。

画面の文字は、WordPress 7.1.3 の日本語の言語パック（画面の日本語の文字を入れるファイル。2026年9月20日の訳）のものです。管理画面そのものは、この記事では見ていません。言語パックが更新されると、文字が少し変わることがあります。

版の表：どこまで上げればいい？

GitHub の告知の欄は、4.7 から 7.1 までの25の系統ごとに、当たる版と直った版を並べています。この25個の「直った版」は、WordPress.org のリリースの一覧で2026年9月22日の日付が付いた25の版と、一つ残らず同じでした（照合しました）。ここには主な6つの系統を載せます。

見るのは、自分の系統の行の「いま上げる先」だけです。たとえば「現在のバージョン: 6.9.4」なら、6.9 の行の 6.9.10 と比べます。6.9.10 は 6.9.9 の次の番号です（点で区切った番号として読み、小数としては読みません）。

系統	いま上げる先（10月6日）	この件が直った版（9月22日）	当たる版
7.1	7.1.3	7.1.2	7.1.0〜7.1.1
7.0	7.0.7	7.0.6	7.0.0〜7.0.5
6.9	6.9.10	6.9.9	6.9.0〜6.9.8
6.8	6.8.11	6.8.10	6.8.0〜6.8.9
6.7	6.7.10	6.7.9	6.7.0〜6.7.8
6.6	6.6.10	6.6.9	6.6.0〜6.6.8

ほかの19の系統（6.5 から 4.7 まで）も、同じ形です。表のとおり、どの系統でも、10月6日の版は、9月22日の版の次の番号になっています。たとえば 6.5 系は 6.5.12 のあとが 6.5.13、4.7 系は 4.7.37 のあとが 4.7.38 です。全部の行は、GitHub の告知と、WordPress.org のリリースの一覧で読めます。

読み方は「同じ系統の中で、直った版より前なら当たる」です。たとえば 7.1.1 は、7.1.2 より前なので当たります。7.1.2 は、この件は直っていますが、上げる先は 7.1.3 です（理由は次の節に書きます）。この件だけを見るなら、9月22日の版以上で直っています。

古い系統にも、同じ日に直しが入りました（backport。新しい版で入れた直しを、古い系統の版にも入れること）。告知は、次のように書いています。

"As a courtesy, the security fix was backported to all branches eligible to receive security fixes (currently through 4.7). As a reminder, only the most recent version of WordPress is actively supported."

訳すと、「好意として、直しを、セキュリティの直しを受けられるすべての系統（いまは 4.7 まで）に入れた。念のため、きちんとサポートしているのは、いちばん新しい版だけだ」です。

4.6 以前は表にありませんが、安全という意味ではありません。4.1〜4.6 は、2025年7月から、セキュリティの直しが出ないと告知されています。この件の直しも 4.7 までです。4.0 以前は、この記事では調べていません。

10月6日の版（7.1.3 など）は、何が違う？

2026年10月6日（日本時間では10月7日の午前2時）に、WordPress 7.1.3 が出ました。告知は、セキュリティの直し7件とバグの直し4件が入っていて、セキュリティの版なので、すぐ更新するよう勧める、と書いています。7件は、CVE-2026-87902 とは別の件で、コメントの管理画面、書き出しの機能、埋め込みなど、いろいろな場所の件です。題は告知に並んでいます。7.1.3 は、JPCERT/CC の Weekly Report の10月15日号でも紹介されました（悪用の話は書かれていません）。

古い系統の10月6日の版（7.0.7 から 4.7.38 まで）は、リリースの一覧に並んでいます。7.1.3 の告知は、古い系統への直しを、必要なら 4.7 まで入れていて、できたものから出す、と書いています（告知の言葉では「作業中」）。

WordPress.org の公開の API（版ごとの状態を答える WordPress.org の仕組み。stable-check）は、2026年10月22日の17時24分ごろ（日本時間）に、次のように答えました。

版	API の答え	意味（英語の語の訳）
7.1.1・7.1.2	insecure	安全でない
7.1.3	latest	いちばん新しい
9月22日の古い系統の版（7.0.6・6.9.9・4.7.37 など）	insecure	安全でない
10月6日の古い系統の版（7.0.7 から 4.7.38 まで24個）	outdated	古い

この記事が上げる先としているのは、この10月6日の版です（latest の 7.1.3 と、outdated の古い系統の版）。

リリースの一覧も、7.1 系については、"Only the most recent in the 7.1 series is safe to use and actively maintained."（7.1 系で、使って安全で、きちんと保守されているのは、いちばん新しいものだけ）と書いています。API の答えの意味の公式の説明は探していないので、ここでは「WordPress.org の API がこう答えた」までにします。つまり、「この件は 7.1.2 で直った。いま上げる先は 7.1.3（古い系統なら10月6日の版）」と、2つに分けて読みます。

2026年10月22日の17時ごろ（日本時間）、7.1.3 より新しい正式版は、リリースの一覧にも GitHub のタグにもありませんでした。10月20日の 7.2-beta1 は並んでいますが、ベータ（試験の版）です。この記事を読む日には、もっと新しい版が出ているかもしれません。上げる先は、管理画面の「更新」の画面が出す版で構いません。

出典: WordPress 7.1.2 の告知・WordPress 7.1.3 の告知・GitHub の告知・WordPress.org: リリースの一覧・WordPress.org: 版ごとの状態の API・WordPress.org: 4.1〜4.6 のセキュリティの直しを止める告知・JPCERT/CC: Weekly Report 2026-10-15 号・WordPress: 更新の文書（日本語）

自動で上がらないのは、どんなとき？

先に、自動更新の仕組みを書きます。WordPress の本体の更新は、3種類に分かれています。開発中の版、マイナー版（保守とセキュリティの版）、メジャー版（大きな版）です。7.1.2 も 7.1.3 も、マイナー版です。WordPress の文書は、自動のバックグラウンド更新は WordPress 3.7 で入り、既定では、ほとんどのサイトで WordPress の自動更新は有効だ、と書いています。すでにあるサイトは、マイナー版を、最初から受け取る設定です。WordPress 5.6 から新しくできたサイトは、版管理のフォルダーが見つかった場合を除いて、メジャー版も最初から自動で上がります。

開発者は、わざとこの設定を最初から有効にしています。

"The core developers made a conscious decision to enable automatic updates for minor releases and translation files out of the box. Going forward, this will be one of the best ways to guarantee your site stays up to date and secure and, as such, disabling these updates is strongly discouraged."

訳すと、「開発者は、マイナー版と翻訳ファイルの自動更新を、最初から有効にすると、よく考えて決めた。これは、サイトを新しく安全に保つ最良の方法の1つになるので、この更新を止めることは強く勧めない」です。

7.1.2 の告知は、自動のバックグラウンド更新に対応したサイトでは、更新が自動で始まる、と書いています。7.1.2 のときに WordPress.org が強制の自動更新を有効にしたかは、告知に書かれていません（7月の 7.0.2 のときは、有効にしたと書いていました）。何割のサイトが上がったかも分かりません。ですから、管理画面で自分の目で確かめます。

自動で上がらない、4つの場合

WordPress の文書とコードから、次の4つが分かります。当てはまるものがあると、自動更新は働きません。

設定で止めている。 設定ファイル wp-config.php（WordPress の設定を書いたファイル）に、自動更新をすべて止める設定（AUTOMATIC_UPDATER_DISABLED）や、本体の自動更新を false にする設定（WP_AUTO_UPDATE_CORE）が書かれている場合です。プラグイン（WordPress に機能を足す部品）が止めている場合もあります
ファイルの書き込みの権限や、持ち主が合っていない。 WordPress の文書は、ボタン1つの更新が、FTP（ファイルをサーバーに送る仕組み）の情報を聞かれずにできるサイトなら、自動の更新もできるはず、と書いています。逆に、FTP の情報を聞かれるサイトは、自動の更新ができません。ボタン1つの更新がうまくいかないのは、たいてい、ファイルの権限の問題だと書いています
版管理のフォルダーがある。 版管理は、ファイルの変更履歴を管理する仕組み（Git など）です。WordPress がそのフォルダーを見つけると、自動更新は止まります
ファイルの変更を止める設定になっている、または、インストールの途中。 本体のコードでは、「ファイルの変更を許さない設定」と「インストール中」のときも、バックグラウンド更新は動きません

更新の確かめは、1日に2回の予定で動きます。

上がったか、上がらなかったかを知る方法

いちばん確かなのは、「ダッシュボード」→「更新」の「現在のバージョン」です（→「管理画面で、いまの版を見る」）。次の3つ（自動更新の1行・サイトヘルス・メール）は手がかりで、特に自動更新の1行は、設定を示すだけの手がかりにすぎません。

「ダッシュボード」→「更新」の画面の、自動更新の1行。 画面には、次の4通りのうち1つが出ます。

画面の文字	意味
このサイトは WordPress のメンテナンスリリースとセキュリティリリースのみで自動的に最新の状態に保たれます。	マイナー版（7.1.2・7.1.3 のような版）が自動で上がる設定。ただし、ファイルの書き込みの問題があると、この表示のままでも上がらない（サイトヘルスで見る）
このサイトは WordPress の新しいバージョンごとに自動的に最新の状態に保たれます。	メジャー版も自動で上がる設定（5.6 から新しくできたサイトの最初の設定）
このサイトは新しいバージョンの WordPress の自動更新を受け取りません。	メジャー版もマイナー版も、自動で上がらない設定
サイトはバージョン管理されているようです。自動更新は無効化されています。	版管理のフォルダーがあるので、自動更新は止まっている

この1行は設定を示すだけで、上がったかどうかは示しません。上がったかは「現在のバージョン」で見ます。下の2つが出ていたら、WordPress の自動更新では上がらない設定なので、「現在のバージョン」が古ければ手で上げます。

サイトヘルスの「バックグラウンド更新」。 左のメニューの「ツール」→「サイトヘルス」を開き、上の「ステータス」を押すと、「バックグラウンド更新」の検査があります。この検査は、自動更新が働く状態かを見るものです。上げる先の版（10月6日の版）まで上がったかは、「現在のバージョン」で見ます。結果の文字は、「バックグラウンド更新が動作中です」（うまくいっている）、「バックグラウンド更新が想定通りに動作していません」（自動更新が働かない理由がある）、「バックグラウンド更新が正常に動作しない可能性があります」（働かない可能性がある）の3通りです。問題がない検査は「テスト通過」のボタンを押すと開く欄にしまわれていて、「動作中です」は、最初は見えません。検査の説明文は、「バックグラウンド更新は使用中の WordPress のバージョンにセキュリティ更新がリリースされた際、自動更新できることを保証します。」です。

働かない理由は、文で出ます。たとえば、「すべての自動アップデートが無効です。」「この WordPress サイトでは更新の実行の際に FTP 認証情報が必要となります。」「一部のファイルが WordPress から書き込みできません:」などです。「この WordPress サイトでは更新の実行の際に FTP 認証情報が必要となります。」のすぐ後ろには、ファイルの持ち主のために FTP で更新している場合の文が続いて出ます。日本語の言語パックの訳では「(このサイトではファイルの所有権の問題のため、更新が FTP 経由で行われます。詳細はホスティング会社にお尋ねください。)」です。前の自動更新が失敗していたときの文（「前回のバックグラウンド自動アップデートは発生しませんでした。」）もあります。

メール。 自動で上がったときは「[…] WordPress ○○ へのサイト更新が完了しました」という題のメールが届く作りです。自動の更新に失敗したときは「[…] WordPress ○○ がご利用いただけます。更新をお願いします。」という題になります（日本語の言語パックの訳）。ただし、失敗のたびに必ず届くとは限りません。

上がっていなかったら

「ダッシュボード」→「更新」の画面で、「バージョン ○○ に更新」のボタンを押します。FTP の情報を聞かれる、書き込めないと言われる、といったときは、上の2番の場合です。自分のサイトのファイルの持ち主や権限は、サーバーの会社の管理画面やマニュアルで確かめます。分からないときは、サーバーの会社に相談します。自動更新を止めている理由が分からないときも、サイトを作った人や、サーバーの会社に確かめてください。

7月の別の件で IPA が書いた一般の注意を引きます。CVE-2026-87902 についての文書ではありません（IPA は、この件の文書を出していません）。

「WordPress.org は、影響を受けるバージョン向けに自動更新による強制更新を有効化したとしています。」「しかしながら、WordPress を運用している環境・構成や設定状況によっては、自動更新が有効ではなかったり、更新に失敗している可能性も考えられます。」「WordPress の管理画面（ダッシュボード）からバージョンアップされているかどうかを確認し、バージョンアップされていない場合には、手動でのバージョンアップを検討してください。」

つまり、「自動のはずだから大丈夫」と決めず、管理画面で自分の目で確かめます。

出典: WordPress: 更新の文書（Upgrading WordPress）・WordPress: 更新の文書（Updating WordPress）・WordPress: 更新の文書（日本語）・WordPress 7.1.2 の告知・WordPress 7.0.2 の告知・IPA: 2026年7月22日の文書

悪用はされている？（2026年10月22日時点）

先に答えを書きます。CISA は、2026年9月25日に、この件を KEV に加えました。KEV は、CISA が出している、悪用が確認された脆弱性の一覧です。一方、WordPress.org の 7.1.2 の告知は、悪用に触れていません。出どころごとに並べます（2026年10月22日の17時20分ごろ〔日本時間〕に確かめました）。

出どころ	書いてあること
CISA の KEV（版 2026.10.21）	CVE-2026-87902 を、2026年9月25日に加えた。アメリカの連邦機関に付く対応の期限は9月28日。ランサムウェア（データを使えなくして身代金を要求する攻撃）に使われたかは、「Unknown」（不明）
CVE の記録の、CISA が付けた「悪用の状況」の欄	「active」（悪用あり）。2026年9月25日の時点
JPCERT/CC	Weekly Report の2026年9月30日号で、国内でも紹介された
WordPress.org の 7.1.2 の告知	悪用の話は無い。「すぐ上げる」ことを勧めるだけ。本文に "exploit" や "in the wild" の語は無い
JPCERT/CC の注意喚起、IPA の重要なセキュリティ情報	9月9日から10月22日までの一覧に、この件の文書は見つからなかった

KEV の短い説明は、条件の話を省いて、「遠隔のコード実行に至る」と書いています。告知と JPCERT/CC の紹介は、「テーマとサーバーの条件がそろうと」「特定の構成で」と、条件つきで書いています。

KEV に加わった、ということが示すのは、悪用が確認された、というところまでです。どのくらいのサイトが入られたのか、どんな被害だったのかを書いた一次資料は、見つかりませんでした。KEV や CVSS の読み方は、脆弱性の知らせの読み方にまとめています。

WordPress の文書は、直しが出たあとの古い版について、次のように書いています。

"If a vulnerability is discovered in WordPress and a new version is released to address the issue, the information required to exploit the vulnerability is almost certainly in the public domain. This makes old versions more open to attack, and is one of the primary reasons you should always keep WordPress up to date."

訳すと、「脆弱性が見つかって、直した新しい版が出ると、その脆弱性を悪用するのに必要な情報は、ほぼ確実に公になる。そのため、古い版は攻撃されやすくなる。これが、WordPress をいつも新しくしておくべき主な理由の1つだ」です。

出典: CISA: KEV・CVE の記録・NVD の API・JPCERT/CC: Weekly Report 2026-09-30 号・JPCERT/CC: 注意喚起の一覧（2026年）・IPA: 重要なセキュリティ情報の一覧（2026年）・WordPress 7.1.2 の告知・WordPress: 強化の文書（Hardening WordPress）

レンタルサーバーで WordPress を動かしている人は？

先に答えを書きます。サーバーの会社が WordPress を上げてくれるかどうかは、会社によります。この記事では、特定の会社の対応や画面の手順は書きません（調べていません）。公的機関の文書にも、「レンタルサーバーの会社が WordPress を自動で上げる」という一般的な一文は見つかりませんでした。ですから、自分で確かめます。

WordPress の管理画面で、「現在のバージョン」を見ます（→「管理画面で、いまの版を見る」）
版の表と比べます（→「版の表：どこまで上げればいい？」）。上がっていなければ、手で上げます（→「自動で上がらないのは、どんなとき？」）
手で上げられない（FTP の情報を聞かれる、書き込めない、など）ときは、サーバーの会社のマニュアルとお知らせを見て、相談します

WordPress の更新の文書は、サーバーの管理画面の道具の中で、ボタン1つで WordPress を更新したり、自動更新を設定したりできる場合がある、と書いています。道具によっては、自動更新が最初から有効だとも書いています。契約しているサーバーのマニュアルで探してください。

WordPress.org にはサーバーの会社に向けた手引きがあり、自動のセキュリティ更新は「ほとんどの場合で有効にすべきだ」と書いていますが、これは会社に向けた勧めで、契約しているサーバーの会社がそうしている証拠ではありません。

PHP の10月21日の件とは、別の話です

10月21日に、PHP の重大な脆弱性2件が出ました。WordPress.org は、その告知で次のように書いています。

"These vulnerabilities are not specific to WordPress and affect any server that hosts a PHP application. No WordPress update is required or planned for these issues."

訳すと、「この脆弱性は、WordPress に限った話ではなく、PHP のアプリを動かすサーバーならどれも当たる。この件のために、WordPress の更新は要らないし、予定もない」です。PHP の件で上げる物は PHP、この記事の件で上げる物は WordPress の本体です。PHP を上げれば WordPress の件も直る、とは、この記事で読んだ文書（WordPress.org の告知・GitHub の告知など）には書かれていません。それぞれ別に確かめてください。

PHP の版は、WordPress の「ツール」→「サイトヘルス」→「情報」→「サーバー」で見られます。確かめ方は、PHP の脆弱性の記事の「レンタルサーバー（WordPress など）・製品の中の PHP：提供元のお知らせを見る」の節に書きました。

本体のほかに、テーマとプラグイン

今回の直しは、WordPress の本体の側に入っています。ただ、WordPress のサーバーの会社向けの手引きは、「WordPress のセキュリティで、いちばん大事なのは、WordPress 本体と、入れているプラグインとテーマを、すべて新しい版に保つこと」だと書いています。更新が出続けているテーマとプラグインを選ぶことも勧めています。強化の文書も、使っていないプラグインは消す、テーマとプラグインは WordPress.org の置き場か、よく知られた会社からだけ入れる、と書いています。

テーマとプラグインは、一つずつ自動更新にする切り替えがあります（プラグインの一覧の「自動更新を有効化」「自動更新を無効化」など）。既定のままなら、テーマとプラグインの自動更新は、本体とは違って、「特別な場合」だけです。WordPress のセキュリティチームが、重大な脆弱性を直すために、API の答えで決める、と文書は書いています。つまり、既定のままなら、本体の自動更新が働いていても、テーマとプラグインは、自分で更新を確かめる必要があります。

サーバーの契約や、WordPress のインストールの流れは、WordPress の始め方にあります。更新や自動更新の話は、その記事には入っていません。

出典: WordPress: 更新の文書（Upgrading WordPress）・WordPress: サーバーの会社向けの手引き（セキュリティ）・WordPress: 強化の文書（Hardening WordPress）・WordPress.org: PHP の重大なセキュリティの版の告知（2026年10月21日）

入られたかもしれないときは？

先に答えを書きます。更新は、弱点をふさぐ手当てです。すでに入られていたかどうかを調べる手当ては、別にあります。

KEV の「求める対応」の欄は、アメリカの連邦機関に向けて、更新だけでなく、CISA の "Forensics Triage Requirements"（フォレンジック・トリアージ。侵害の痕跡を調べる、最初の調査のことです）にも従うよう書いています。CISA の BOD 26-04（更新の優先順位の付け方を連邦機関に求める指令）の実施の手引きも、"The requirement of BOD 26-04 is that an adequate forensic triage analysis is performed"（BOD 26-04 が求めるのは、十分なフォレンジック・トリアージの分析が行われることだ）と書いています。KEV のこの件の行も、フォレンジック・トリアージの欄が「Yes」です。日本のサイトに、そのまま当てはまる決まりではありません。ただ、「上げたから、入られていない」とは、決められないことが分かります。

入られたかもしれないと思ったときの手順は、WordPress.org の文書に、サイトがハッキングされた場合の FAQがあります。手順の中身は、この記事には写しません。リンク先を読んでください。その文書は、共用のサーバー（ほかの人のサイトと同じサーバー）を使っているなら、サーバーの会社に確かめるよう書いています。

"Check with your hosting provider." "The hack may have affected more than just your site, especially if you are using shared hosting. It is worth checking with your hosting provider in case they are taking steps or need to."

訳すと、「サーバーの会社に確かめる」「被害は、自分のサイトだけにとどまらないかもしれない。共用のサーバーなら、特にそうだ。会社が対応を進めているか、対応が要るかを、確かめる価値がある」です。

サイトの守りの点検全体は、Web 開発のセキュリティの基本にまとめています。

出典: CISA: KEV・CISA: BOD 26-04 の実施の手引き・WordPress: サイトがハッキングされた場合の FAQ

資料によって違って見えるところ（ほかの資料と見比べる人へ）

この記事の版の表のとおりに上げていれば、やることは変わりません。ほかの資料と見比べたときに食い違って見える、点数・呼び名・当たる版の範囲を、まとめます。

点数は、誰が付けたもの？

点数は、見る場所で違います。CVSS は、脆弱性の深刻さを点数で表す共通の方式で、4.0 や 3.1 は方式の版です。どちらかに揃えず、「誰が、どの版で付けた点か」を並べます。

出どころ	付け方	点
WordPress（GitHub の告知）	CVSS 4.0	9.2（critical）
CISA（CVE の記録の CISA の欄）	CVSS 3.1	8.1（HIGH）
WordPress.org の告知	点数なし	「critical severity」と書くだけ

NVD（アメリカの脆弱性のデータベース）に出ている点数は、この CISA の点だけです。NVD 自身が付けた点は、確かめた時点ではありませんでした。点が高いことと、自分が受ける被害の大きさは別です。読み方は、脆弱性の知らせの読み方にまとめています。

呼び名が、資料によって違います

GitHub の告知は、この件を「ページのテンプレートを決める処理での、認証なしのパストラバーサル。条件つきで RCE」（英語の題は "Unauthenticated path traversal in page-template resolution leading to conditional RCE"）と呼び、KEV の名前と JPCERT/CC の見出しは「リモートファイルインクルージョン」です。「リモート」と付いていますが、告知が書く読み込み先はサーバーの上の（ローカルの）ファイルで、名前の理由を書いた文は見つからなかったので、同じ件の別の呼び名として読んでください。

当たる版の範囲が、資料によって違う

当たる版の範囲は、資料によって書き方が違います。

GitHub の告知: 4.7 から 7.1 までの25の系統ごとに、当たる版と直った版を書く。4.7 より前は書かない
CVE の記録: 「0 から 7.1.2 より前」を1行で書く。古い系統の直った版を書いていない。そのまま読むと、7.0.6 や 6.9.9 まで「当たる」に見える
NVD: GitHub の告知と同じ25の境目だが、一番目を「4.7.37 より前すべて」とし、4.6 以前も当たる側に入れている

この記事は、GitHub の告知と、リリースの一覧を使いました。4.6 以前は「直しが出ない」と書いています。

出典: GitHub の告知・CVE の記録・NVD の API・WordPress 7.1.2 の告知・CISA: KEV・JPCERT/CC: Weekly Report 2026-09-30 号

よくある質問

7.1.2 に上げました。それで足りますか？

この件（CVE-2026-87902）は、7.1.2 で直っています。ただし、10月6日に 7.1.3 が出ていて、WordPress.org の API は、7.1.2 を「insecure」と返します。7.1.3 の7件は、この件とは別です。7.1.3 に上げてください（→「10月6日の版（7.1.3 など）は、何が違う？」）。

古い版（6.x や 5.x）を使っています。直しはありますか？

4.7 系までは、9月22日の版が出ています。たとえば 6.9 系は 6.9.9、5.9 系は 5.9.18 です。いま上げる先は、10月6日の版です。ただし、告知がきちんとサポートしているのは、いちばん新しい版だけで、古い系統への直しは「好意で」出したものです。4.6 以前は、直しが出ません（→「版の表：どこまで上げればいい？」）。

自動で上がったかどうかは、あとから分かりますか？

「ダッシュボード」→「更新」の「現在のバージョン」で分かります。自動更新の設定の1行や、サイトヘルスの「バックグラウンド更新」、更新のメールも手がかりです（→「上がったか、上がらなかったかを知る方法」）。

テーマを替えれば、当たらなくなりますか？

告知も、GitHub の告知も、JPCERT/CC の紹介も、直し方は「直った版に上げる」ことだけを書いています。テーマを替える手立ては、どれにも書かれていません。どのテーマが当たるかの一覧も、見つかりませんでした。ですから、当たるかを調べるより先に、本体を上げます。直しは本体の側に入っていて、テーマの側の更新を待つ話ではありません（→「自分の WordPress は直っている？どう確かめる？」）。

PHP を10月21日の版に上げました。WordPress も直りましたか？

別の話です。PHP を上げれば WordPress の件も直る、とは、この記事で読んだ文書（WordPress.org の告知・GitHub の告知など）には書かれていません。WordPress 本体の版を、管理画面で確かめてください（→「PHP の10月21日の件とは、別の話です」）。

自分の WordPress で確かめること（チェックリスト）

「ダッシュボード」→「更新」の「現在のバージョン」が、自分の系統の上げる先（7.1 系なら 7.1.3）以上か（4.6 以前なら、直しが出る系統まで上げる計画があるか）（→「版の表：どこまで上げればいい？」）
上がっていなければ、「バージョン ○○ に更新」のボタンで手で上げたか。FTP の情報を聞かれる、書き込めない、といったときは、サーバーの会社に相談したか（→「自動で上がらないのは、どんなとき？」）
自動更新の1行が「受け取りません」「バージョン管理されている」なら、自動では上がらない設定だと分かったか。サイトヘルスの「バックグラウンド更新」も見たか（→「上がったか、上がらなかったかを知る方法」）
レンタルサーバーなら、サーバーの会社のお知らせとマニュアルを見たか（→「レンタルサーバーで WordPress を動かしている人は？」）
PHP の10月21日の件は、別に確かめたか（→「PHP の10月21日の件とは、別の話です」）
入られたかもしれないと思ったら、WordPress.org の FAQ を読み、サーバーの会社にも確かめたか（→「入られたかもしれないときは？」）

まとめ

2026年9月22日に、WordPress 7.1.2（と、古い系統の9月22日の版）が出た。重大な脆弱性1件（CVE-2026-87902）の直しで、テーマとサーバーの条件がそろうと、ログインなしで、外から機械を好きに動かされる恐れがある。直し方は、この記事で読んだ文書では、直った版に上げることだけ
直った版は、系統ごとに違う（7.1 系は 7.1.2、7.0 系は 7.0.6、6.9 系は 6.9.9）。いま上げる先は10月6日の版（7.1 系は 7.1.3）。7.1.2 は、WordPress.org の API が「insecure」と返す（2026年10月22日 17時24分ごろ）。4.6 以前は直しが出ない
確かめ方は、「ダッシュボード」→「更新」の「現在のバージョン」。サイトヘルスの「バックグラウンド更新」も見る
自動更新は、ほとんどのサイトで既定で有効で、止めるのは強く勧められていない。ただし、設定で止めている、ファイルの権限が合わない、版管理のフォルダーがある、などで上がらない。7.1.2 のときに強制の自動更新を有効にしたのかは、告知に書かれていない
悪用は、CISA が2026年9月25日に KEV に加えた。国内でも JPCERT/CC の Weekly Report（9月30日号）で紹介された。WordPress.org の 7.1.2 の告知は、悪用に触れていない。入られたかもしれないときは、WordPress.org の FAQ とサーバーの会社へ
10月21日の PHP の件とは、上げる物が別（PHP と WordPress 本体）
この記事で確かめていないこと：管理画面の実際の表示、何割のサイトが自動で上がったか、レンタルサーバーの会社ごとの対応、自動更新のメールの送り先、10月6日の古い系統の版が出た時刻（リリースの一覧の日付と同じか）、API の答えの意味の公式の説明、7.1.3 の7件の番号と重さ、4.0 以前の扱い、悪用の中身（被害の数など）、攻撃を試すためのコードの有無

同じ時期の話として、10月21日の PHP の脆弱性はPHP の脆弱性に書きました。