WordPress本体の更新の最中に、認証なしでコードを実行されうる脆弱性が、11月3日に悪用確認リストへ載った。期限は11月6日 ── 担当サイトの更新の窓と、前後の記録を確かめる13項目（2026年11月時点）

目次

1. 01 何が書いてあるか — 更新の最中に、認証なしの攻撃者がコードを実行できうる、とリストは書く
   1. リストの項目が書いていること
   2. WordPressの2つの文書の言い方
   3. 4つの書き方を並べる
   4. この記事で扱わないこと
2. 02 なぜ・背景 — 「更新すれば安全」の手前に、更新の最中がある
   1. 競合状態は、確かめた後と使う前の隙間で起きる
   2. 「更新の窓」は、更新が動いている間の時間
   3. 修正は、更新の仕組みの部品に入っている
   4. 期限が3日なのは、侵害の調査の欄があるから
3. 03 用語 — 出てくる言葉を、先にそろえる
4. 04 型別 — 誰に関係があり、何が分からず、どう確かめるか
   1. 🅰 適用範囲 — WordPressの本体を、更新して使っているサイト
   2. 🅱 この情報が測っていないこと
   3. 🅲 手順1 — 担当サイトの一覧に、3つの列を足す
   4. 🅲 手順2 — 版と、更新の状態をコマンドで読む
   5. 🅲 手順3 — 更新が動いた時刻を、残っている記録から拾う
   6. 🅲 手順4 — 更新の前に、ログと現状を保存する
   7. 🅲 手順5 — 窓の前後を、アクセスログで読む
   8. 🅲 手順6 — 更新の後に、印と整合を見る
   9. 🅲 手順7 — 更新の窓を短くする（筆者の案）
5. 05 明日、担当サイトで確認できることチェックリスト
6. 06 代替・他の選択肢 — 更新の方式ごとに、窓の扱いが違う
   1. 更新の方式で、決められることが違う
   2. 自動更新を止めるかは、別の判断
   3. 更新できない枝のサイトは、別の話
7. 07 筆者が確かめたこと — 期限は3日か14日で、侵害の調査ありの項目は、すべて3日だった
   1. 期限は、3日か14日のどちらかだった
   2. WordPress本体の項目は、2026年に4件加わっている
   3. 確かめていないこと
8. 08 このテーマは、ここまで — 版・自動更新・期限・痕跡の記録
   1. 日付つきの流れ
   2. 当サイトの、関連する過去の記事
   3. 今回の記事の位置
9. 09 この記事のまとめ

01 何が書いてあるか — 更新の最中に、認証なしの攻撃者がコードを実行できうる、とリストは書く

CISAは2026年11月3日、WordPress本体の脆弱性（CVE-2026-119977）を、悪用が確認された脆弱性のリスト（KEV）に加えた。リストの説明の要旨はこうである。認証なしの攻撃者が、更新の窓（upgrade window）の間に、サーバー上でコードを実行できうる。原因は、フルパッケージでの本体の更新で使われる、予測できて、Webから届く一時的な置き場にある、と書く。期限は2026年11月6日で、この記事を書いた11月4日の時点では、期限まであと2日である。

10月28日のWordPress 7.1.4の告知にも、更新の処理の弱点が書かれていた。つまり、この脆弱性は「更新しないと危ない」だけでなく、「更新している最中が危ない」と読める。この記事の中心は、その最中の長さと、前後の記録である。版の一覧づくりや、自動更新の確かめ方は、このサイトの別の記事にある（後半でリンクする）。ここでは、更新の最中と前後の確認に絞る。

リストの項目が書いていること

リストの項目は、決まった欄に分かれている。WordPressの項目の、欄ごとの内容を並べる。

• 製品: WordPress本体（Core）
• 弱点の型: CWE-367。確認した時と使う時の間に状態が変わる、競合状態
• 追加日: 2026年11月3日
• 期限: 2026年11月6日（追加日の3日後）
• 侵害の調査の欄: あり
• ランサムウェアの攻撃での使用の欄: 不明（Unknown）
• 必要な対応の欄: 提供元の指示どおりの緩和策を行う。CISAの指令（BOD 26-04）と、侵害の調査の要件に従う。クラウドのサービスでは、BOD 26-04の該当する指針に従う。緩和策が無ければ、製品の利用をやめる

WordPressの2つの文書の言い方

WordPress 7.1.4の告知は、これをセキュリティリリースと呼び、直ちに更新するよう勧めている。修正の1つとして、「更新の処理の弱点で、更新中に遠隔でコードが実行されうるもの」を挙げる。自動更新に対応しているサイトでは、更新が自動で始まる、とも書く。

同じ日付の変更記録のページは、同じ件を「本体の更新中の競合状態で、遠隔でコードが実行されうるもの」と書く。このページは、7.1.4で直った修正の数を22件と数え、7.0と6.9は22件すべてが当たると書いている。古い枝ほど当たる件数は減り、たとえば6.8と6.7は20件、6.3から6.0と5.9は9件、4.9は4件、4.8と4.7は2件である。ただし、更新の窓の件が、どの枝の何件に含まれるかは、ページに書かれていなかった。

4つの書き方を並べる

同じ弱点を、4つの文書がどう書いているかを、表に並べた。

4つを並べて分かるのは、どの文書も、一時的な置き場の名前や場所を書いていないことである。理由は書かれていない。この記事も書かない。知らなくても、更新の最中を短くし、前後を記録に残す確認はできる。

この記事で扱わないこと

攻撃の手順、置き場の探し方は扱わない。WordPressの使い方の入門や、特定の会社のサービスの評価も扱わない。また、当サイトはWordPressを使っていない。「当サイトのWordPressを更新した」という話は、この記事には出てこない。確かめるのは、担当サイトで行う手順であり、当サイトで確かめたのは、公開されているデータの数え直しだけである（07章）。

02 なぜ・背景 — 「更新すれば安全」の手前に、更新の最中がある

競合状態は、確かめた後と使う前の隙間で起きる

CWE-367の説明の要旨は、こうである。製品は、ある資源の状態を使う前に確かめるが、確かめた後、使う前に、その状態が変わって、確かめた結果が成り立たなくなる。筆者のたとえで言えば、書類を確かめて印を押す間に、書類が差し替えられた状況である。

WordPress本体の更新でこの型が起きる、とリストは書く。更新の間は、新しいファイルを一時的に置き、確かめ、入れ替える。その間の、確かめた後と入れ替えの前の隙間に、外から手を出せる、という図である（筆者の読み。どの隙間かは、文書が書いていない）。

「更新の窓」は、更新が動いている間の時間

リストが使う「アップグレードの窓」は、更新が始まってから終わるまでの時間を指すと読める。この記事では「更新の窓」と呼ぶ。更新のたびに窓は開き、閉じる。更新の回数で窓の数が、1回にかかる時間で窓の長さが決まる（筆者の整理）。

窓が短いほど、攻撃を受ける機会は減ると考えられる。ただし、窓の長さと危険の大きさの関係を、公式の文書は書いていない。窓を短くするのは、筆者の案であって、公式が勧める対策ではない。

修正は、更新の仕組みの部品に入っている

変更記録のページは、7.1.4で直したファイルの一覧を載せている。その中に、管理画面の更新の処理に関わる名前のファイルが2つ含まれていた（名前に「upgrader」「update-core」を含むもの）。ページは、どのファイルがどの修正に対応するかを書いていない。2つが更新の窓の件の修正かは分からないが、リストの説明とは向きが合っている（筆者の読み）。

古い枝への修正は、告知（10月28日）が「順次出る」と書いた。11月4日に変更記録のページを開くと、4.7から7.0までの各枝に、修正入りの版が出た、と書かれていた。7.1の枝は、7.1.4が修正入りの版である。7.2のベータは、Beta 3が7.1.4と同じ日に出て、告知は「適用できる修正をすべて含む」と書く。なお、4.6以前は、もうセキュリティの更新を受けない、とページは書いている。

期限が3日なのは、侵害の調査の欄があるから

リストの期限は、追加日の3日後だった。CISAの指令（BOD 26-04）の本文は、「侵害の調査」の印が付いた項目は、3日のうちに修正か緩和を終え、あわせて、資産が侵害されていないかを調べると書く。3日という短さは、更新が遅れると侵害がありうる、という見方を反映している（筆者の読み）。

拘束されるのは、アメリカの連邦機関である。一般のサイトは、優先順位の目安として読む。読み替え方は、CISAの悪用確認リストにPHPの2件が載り、期限の欄は10月29日だった。拘束されるのは米国の連邦機関で、一般のサイトは優先順位の目安として読む ── 担当サイトの更新期限に読み替える13項目（2026年10月時点）と、PHPの2件の脆弱性が悪用リストに載り、期限は10月29日だった ── 期限の日に当サイトで確かめた4つと、自分の記事の言い過ぎ、期限を自分のサイトの期限に読み替える方法に書いたので、ここでは繰り返さない。

03 用語 — 出てくる言葉を、先にそろえる

04 型別 — 誰に関係があり、何が分からず、どう確かめるか

🅰 適用範囲 — WordPressの本体を、更新して使っているサイト

対象は、WordPressを使っているサイトである。更新の方式は、少なくとも4つある。WordPressの文書は、自動のバックグラウンド更新、管理画面の1クリックの更新、手動の更新を挙げる。コマンドで更新するWP-CLIも、公式の文書にある。ホスティング会社が自分の画面から更新する機能を持つ場合もある（文書は、cPanelやPleskの管理ツールの例を挙げる）。

どの方式がこの弱点に当たるかを、リストも告知も書いていない。そのため、この記事は、4つの方式のどれにも「安全」と言わない。

🅱 この情報が測っていないこと

リストの項目は、攻撃の規模、手口、被害の件数を書いていない。一時的な置き場の名前も、更新の窓の長さも書いていない。ランサムウェアの攻撃での使用の欄は「不明」である。告知は、「更新中でなければ安全」とも「自動更新なら安全」とも書いていない。この記事も、言い切らない。

この記事は、自分で攻撃を試していない。担当サイトで窓を測った結果も、持っていない。

🅲 手順1 — 担当サイトの一覧に、3つの列を足す

担当サイトの一覧に、列を3つ足す。「更新の方式」「最後に更新が動いた日時」「窓の前後のログの保存場所」である。一覧づくりは、PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要る ── 台帳の8列を埋めて確かめる13項目（2026年10月時点）と、WordPress 7.1.4は10月28日に出て、公式は直ちに更新するよう勧めた ── 担当サイトの版を一覧にして更新の期限を決める13項目（2026年10月時点）に書いた。

🅲 手順2 — 版と、更新の状態をコマンドで読む

WP-CLIが使えるサイトでは、次の2つで、いまの版と、出ている更新を読める。画面で見るなら、管理画面の更新の画面に、同じ情報が出る。

wp core version
wp core check-update --force-check

1つ目は、入っている版を出す。2つ目は、出ている更新を表で出し、--force-checkを付けると、キャッシュを使わずに確かめ直す、とWP-CLIの文書にある。出た版を、一覧に書き写す。

🅲 手順3 — 更新が動いた時刻を、残っている記録から拾う

更新がいつ動いたかは、更新の窓の位置を決めるのに要る。拾える場所は3つある。1つ目は、自動更新の結果のメールである。WordPressの文書は、自動更新のメールを止める設定の例を載せていて、その例の説明から、成功・失敗・重大の3種類のメールが標準で送られる、と読める。2つ目は、ホスティング会社の画面の履歴である。3つ目は、更新で入れ替わるファイルの更新日時である。

stat -c '%y %n' wp-includes/version.php

3つ目は、更新が終わった時刻の近くになることが多い（筆者の案）。ファイルの置き方で変わるので、メールや履歴と突き合わせる。どれも見つからなければ、「不明」と書く。

🅲 手順4 — 更新の前に、ログと現状を保存する

CISAの実施の手引きは、侵害の調査の手順として、修正を入れる前に、証拠を集めることを求めている。理由は、修正で、証拠になる情報が失われるおそれがあるからである。担当サイトの更新でも、同じ順番が使える。更新の前の保存は、更新の窓の外で行うので、窓を長くしない。

保存するものは、3つである。Webサーバーのアクセスログ（圧縮されたものを含む）と、本体のファイルが公式のものと一致しているかの結果、そして、更新を始める前の版である。2つ目は、次のコマンドで取れる。

wp core verify-checksums --include-root

WP-CLIの文書によると、このコマンドは、WordPress.orgのチェックサムと、入っているファイルを突き合わせる。--include-rootを付けると、ルートの直下にある、WordPressのものではないファイルについて、警告が出る。なお、うまく確かめられないときは、管理画面の更新の画面に出ている版と言語の値を、--versionと--localeで指定するように、とWP-CLIの文書にある。

ログの数え方は、PHPの脆弱性の「痕跡」は、ログに無いこともある ── 圧縮されたログ・エラーの出る先・回転の直後を落とさずに、件数で数える13項目（2026年10月時点）に書いた。更新の前に診断情報を保存する考え方は、SiteGuard Server Editionの脆弱性は、開発元が悪用を確認している。更新の前に診断情報を保存する ── サイトの前に置いた部品の台帳を作って確認する13項目（2026年10月時点）にもある。

🅲 手順5 — 窓の前後を、アクセスログで読む

手順3で見つけた更新の開始と終了の時刻を使って、その前後30分のアクセスの記録を取り出す。30分は、筆者が決めた幅で、公式の数字ではない。取り出したら、状態コード別の件数と、リクエストされた場所の上位10件を数える。ログの書式はサーバーによって違うので、列の位置は、先に1行を見て確かめる。

grep '04/Nov/2026:02:' access.log | awk '{print $9}' | sort | uniq -c | sort -rn

上の例は、ある書式で9列目が状態コードのときの書き方である。時刻の部分と列の番号は、担当サイトのログに合わせて直す。見るのは、いつもの日と比べて、初めて見る場所への要求が増えていないかである。同じ時間帯の3日前までのログも同じ数え方で数え、並べる。ログの量が多いサイトでは、🔧 【セキュリティ】IPA提供 攻撃兆候検出ツール iLogScanner で簡単ログ分析ツール　★iLogツカウン（要ログイン）のように、攻撃の兆候を探す道具を使う手もある。このツールが、今回の窓の件の兆候を見つけられるかは、確かめていない。

🅲 手順6 — 更新の後に、印と整合を見る

更新が終わったら、3つを見る。1つ目は、更新が途中で止まった印が残っていないかである。WordPressの更新の文書は、自動更新が失敗した後に、「失敗した更新」の通知が出て、.maintenanceというファイルを消す手順を書いている。更新が終わった後に、このファイルが残っていれば、更新が完了していない可能性がある（筆者の読み）。

2つ目は、手順4と同じコマンドで、ファイルの整合を見ることである。結果が、更新の前と比べて、どう変わったかを一覧に書く。3つ目は、管理者の一覧を取ることである。

wp user list --role=administrator

WP-CLIの文書によると、--roleを付けると、その役割の利用者だけが出る。知らない名前が増えていないかを、更新の前の一覧と比べる。

🅲 手順7 — 更新の窓を短くする（筆者の案）

窓を短くする工夫を、筆者の案として並べる。どれも、公式が勧めたものではなく、効果は確かめていない。

• 更新の前に、バックアップとログの保存を済ませる。窓の中の作業を、更新そのものだけにする。
• 手動で更新するサイトでは、アクセスの少ない時間を選ぶ。窓を開く時刻を、自分で決められるからである。
• 更新の最中だけ、管理者のアドレス以外からの接続を絞れるかを、ホスティング会社に聞く。
• かかった時間を毎回控え、次の更新と比べる。
• 自動更新に任せるサイトは、窓の時刻を決められない。そのかわり、更新の結果のメールを残し、更新の後の確認（手順5と6）を、翌日までに行う。

3番目の案は、置き場がWebから届く、というリストの説明を受けた考えである。絞った接続で守られるかは分からないので、案にとどめる。

05 明日、担当サイトで確認できることチェックリスト

以下は、担当サイトの更新の窓と、その前後の記録を確かめて、一覧に書く13項目である。1〜2番目は公式の文書の読み取り、3〜7番目は担当サイトの版と更新の状態を一覧にする作業、8〜9番目は更新の前の保存、10〜13番目は更新の窓と、その後の確認である。1項目は5分以内でできる。チェックの状態は、お使いのブラウザに保存され、サーバーには送られない。

• CISAの悪用確認リストのデータを開き、CVE-2026-119977の期限（11月6日）と、侵害の調査の欄を、メモ帳に書き写す
• WordPress 7.1.4の告知を開き、更新の処理の弱点を書いた1文と、古い枝への修正の2文を、メモ帳に書き写す
• 担当サイトを1枚の一覧に並べ、WordPressを使うサイトの件数を数える
• WordPressを使うサイトの各行に、更新の方式（自動・画面・コマンド・事業者）を1語で書く
• 各サイトの版を、wp core versionか管理画面の更新の画面で読み、一覧に書く
• 7.1.4か、自分の枝の修正入りの版になっていないサイトに、更新する日時を1つ決めて書く
• 最後に更新が動いた日時を、メールかホスティング会社の履歴で探し、一覧に書く（見つからなければ「不明」と書く）
• 更新の前に、アクセスログの保存先と保存した日付を、一覧に書く
• 更新の前に、wp core verify-checksumsを実行し、警告の件数を一覧に書く
• 更新の始めと終わりの時刻を控え、差を分と秒で、一覧に書く（窓の長さ）
• 窓の前後30分のアクセスの記録を取り出し、状態コード別の件数と、初めて見る場所の数を一覧に書く
• 更新の後に、.maintenanceのファイルが残っていないかを見て、結果を「あり」か「なし」で一覧に書く
• 更新の後に、管理者の一覧を取り、知らない名前の件数を、更新の前の一覧と比べて書く

06 代替・他の選択肢 — 更新の方式ごとに、窓の扱いが違う

更新の方式で、決められることが違う

更新の方式によって、担当者が決められることが違う。筆者の整理を、表にした。公式の文書が、この整理を書いているわけではない。

自動更新を止めるかは、別の判断

自動更新を止めれば、窓の時刻を決められる。ただし、WordPressの文書は、自動更新を止めることを「強く勧めない」と書く。文書は、小さな版（修正やセキュリティの版）の自動更新を、標準で有効にしたのは意図した判断で、サイトを最新で安全に保つ最も良い方法の1つだからだ、と説明している。そのため、窓の時刻を決めたいという理由だけで止めると、更新が遅れる危険が増える。止めるなら、更新の担当と日程を、先に決める。

更新できない枝のサイトは、別の話

変更記録のページによると、4.6以前の枝は、もうセキュリティの更新を受けない。この枝のサイトは、更新の窓以前に、更新の道が無い。該当があれば、更新できる枝への移行か、公開の停止かを、担当者と決める。リストの欄にある、緩和策が無ければ利用をやめる、という対応が参考になる。

07 筆者が確かめたこと — 期限は3日か14日で、侵害の調査ありの項目は、すべて3日だった

当サイトはWordPressを使っていないので、窓を測る確認は行っていない（WordPress 7.1.4は10月28日に出て、公式は直ちに更新するよう勧めた ── 担当サイトの版を一覧にして更新の期限を決める13項目（2026年10月時点）に、当サイトの入口を外から見た結果がある）。この章は、公開されているリストのデータを、筆者が数え直した結果である。

期限は、3日か14日のどちらかだった

2026年11月3日付のリスト（1,767件）のうち、2026年6月10日以降に加わったのは150件だった。6月10日は、BOD 26-04が出た日である。この150件の期限は、追加日の3日後が120件、14日後が30件で、これ以外の日数は無かった。

ここから言えるのは、侵害の調査ありの97件は、すべて期限が3日だったことである。逆に、期限が3日でも、調査なしの項目が23件ある。期限の日数だけでは、調査が求められているかは分からないので、調査の欄は別に読む。この数え方は、欄の値だけを見たもので、各項目の中身の重さは比べていない。

WordPress本体の項目は、2026年に4件加わっている

同じデータで、製品が「WordPress本体」の項目を探すと、2026年には4件があった。7月21日に2件（組み合わせて、認証なしでコードを実行できうる、とリストは書く）、9月25日に1件（ページの雛形を選ぶ処理に、読めるPHPファイルを取り込ませる、と書く）、そして11月3日の今回の1件である。4件のうち3件（7月21日の1件、9月25日、今回）は、期限が3日で、侵害の調査の欄があった。残る1件（7月21日のもう1件）は、期限が14日で、調査の欄は無かった。

確かめていないこと

リストの件数は、攻撃の多さを示す数字ではない。WordPress本体の項目が増えた理由も、データからは分からない。更新の窓の長さも、この記事は測っていない。

08 このテーマは、ここまで — 版・自動更新・期限・痕跡の記録

日付つきの流れ

• 2026年6月10日: CISAがBOD 26-04を出し、期限を、リスクに基づいて決める形にした。
• 2026年7月21日・9月25日: WordPress本体の項目が、リストに加わった（07章の数え方）。
• 2026年10月28日: WordPress 7.1.4が出た。更新の処理の弱点が、修正の1つに入っていた。
• 2026年11月3日: CISAが、この弱点（CVE-2026-119977）を、リストに加えた。期限は11月6日。
• 2026年11月4日: この記事のために、リストのデータと公式の文書を開き直した。

当サイトの、関連する過去の記事

• WordPress 7.1.4は10月28日に出て、公式は直ちに更新するよう勧めた ── 担当サイトの版を一覧にして更新の期限を決める13項目（2026年10月時点）: 7.1.4の修正を6つの領域に分け、版を一覧にした記録。この記事は、同じ版の更新の最中に絞った。
• WordPressは5日の間に、セキュリティ更新が2回出た ── 担当サイトの版・自動更新・バックアップを一覧で確かめる13項目（2026年10月時点）: 自動更新とバックアップを確かめた記録。
• CISAの悪用確認リストにPHPの2件が載り、期限の欄は10月29日だった。拘束されるのは米国の連邦機関で、一般のサイトは優先順位の目安として読む ── 担当サイトの更新期限に読み替える13項目（2026年10月時点）: 期限の欄の読み方の記録。
• PHPの脆弱性の「痕跡」は、ログに無いこともある ── 圧縮されたログ・エラーの出る先・回転の直後を落とさずに、件数で数える13項目（2026年10月時点）: ログを落とさず数えた記録。
• PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 修正が入ったかを値で確かめる4つの方法と、3本目の知らせ（CVE-2026-115560）を当サイトで確かめた記録: 版の表示が修正の証拠にならなかった記録。
• PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録: 更新の順番と更新後の確認の記録。

今回の記事の位置

これまでの記事は、版と期限が中心だった。今回は、更新が動いている間と、前後の記録に絞った。更新の前に複製で試す手順は、対になる記事のWordPress 7.2 Beta 4は「本番に入れない」試験版で、Beta 3は7.1.4に同梱された ── 本番の更新の前に、複製で更新の所要時間を測り、複製が外へ手を出さないことを確かめる13項目（2026年11月時点）に書いた。複製で更新して時間を測れば、本番の窓の長さの目安になる（筆者の案）。

当サイトの無料ツールも使える。🔧 【セキュリティ】WEBサイトの 外からできるセキュリティ対策監査ツール★ミエルン（要ログイン）は、外から見える情報を集めてリスクを評価するとされている。更新の前後で結果を取って比べる使い方を、筆者は考える。今回の窓の件を見つけるかは、確かめていない。🔧 【メンテナンス】WEBサイトの状況チェック・比較ツール　★チガウン（要ログイン）は、サイト内を回ってソースをチェックするとされている。更新の前後の比較に使えるかは、使う前にツールのページで確かめてほしい。