WordPress更新中の脆弱性が悪用確認済みに：CVE-2026-119977の対象版と対処

出典は公式リリース、CVEレコード、CISA公式KEVデータです。KEVの登録日が11月3日だからといって、その日に攻撃が始まったとは限りません。攻撃の開始日時、国内の被害件数、個別サイトの侵害状況は、この情報だけでは分かりません。

KEVには対応期限として11月6日、ランサムウェアキャンペーンでの使用はUnknownと記録されています。期限は米国の該当する連邦機関向けの運用と関係するもので、日本企業がその日まで安全に待てるという意味ではありません。実悪用という根拠を受け、公開サイトの管理者は早急に対象確認と対応判断を進めるべきです。

CVEの説明では、フルパッケージによる本体更新時に、予測可能でWebから到達できる一時的な展開先が使われることを原因として挙げています。更新途中の限られた時間に攻撃が成立し得る問題です。分類はCWE-367、確認した時点と実際に使う時点の間に状態が変わる「TOCTOU」の競合状態です。

たとえるなら、店舗の改装で資材を仮置きした場所が、作業員だけでなく外の人からも触れる状態になるようなものです。通常のページを表示しているときだけを見ていては、更新作業中の状態を見落とします。ただし、このたとえから具体的な攻撃手順や、すべての更新方式が同じ条件になると推定してはいけません。

「利用者の操作不要」は、更新処理なしで常に攻撃できる、という意味ではありません。また、AC:Hだから放置できるとも判断できません。成立条件と実悪用の事実の両方を見て、更新の優先順位を決めます。

現行の7.1系列では7.1.0〜7.1.3が対象、7.1.4が修正版です。旧系列にも修正が戻されています。公式7.1.4解説とCVEの系列別範囲を照合した表を示します。これらは本件への修正が入った版であり、古い系列を長期運用してよい保証ではありません。公式は最新の版のみを積極的なサポート対象と説明しています。

4.6以前は公式にセキュリティ更新の対象外とされています。このCVEの表にないことを、古いサイト全体が安全という意味に読み替えないでください。ホスティング会社が独自に修正を適用したと説明する場合も、表示される版だけで決めず、本件CVEへの対応文書と適用証跡を確認します。

以下は公式の更新方法を踏まえ、本誌が整理した運用上の推奨です。WordPress実機での再現や更新試験は行っていません。本番環境の変更は、自社の管理者または契約している保守担当者が実施してください。

1. 1対象を洗い出す。本番、別ドメインのキャンペーンサイト、検証環境、休眠サイトを含め、管理画面や承認済み台帳でWordPress本体の版、更新方式、直近の更新日時、担当者を記録する。マネージドサービスは運営元の回答を根拠にする。
2. 2侵害の兆候があれば、通常の更新作業と切り分けて担当部門へ連絡する。不審なファイルや管理者の追加、予期しない外部転送などの発見日時を記録し、ログや関連ファイルを保全する。証拠を消す削除・初期化を先に行わない。
3. 3更新前の復元手順とバックアップを確認する。侵害の疑いがある場合、最新バックアップを無条件に正常とみなさず、保全用と復旧用を区別して調査する。
4. 4保守担当者と、更新中の公開範囲を制御する。Webサーバーやホスティング側で非管理者のアクセスを一時制限するなど、対象の展開先も含めて届かなくなる構成を検討する。アプリ内のメンテナンス画面だけで十分と決めつけず、更新用の通信や復旧手段への影響も確認する。
5. 5公式配布元またはホスティング会社の承認済み経路で、修正済みの版へ更新する。管理画面の「ダッシュボード→更新」が標準の入口。旧系列から大きく上げる場合は、公式の更新手順と互換性確認を併用する。
6. 6更新後、実際に稼働する本体の版、ログイン、投稿・表示、フォーム等の主要機能を確認する。配布ファイルを取得しただけで完了にしない。全台・全サイトの反映を記録してから、制限解除を判断する。
7. 7過去の公開状態での更新履歴と、残っているアクセス・変更記録を点検する。修正適用と侵害調査の完了欄を分け、記録が不足する部分は未確認のまま担当者へ引き継ぐ。

更新方法の出典はWordPress公式の更新ガイドです。今回の外部到達性の制限は、脆弱性の成立条件から考えた本誌の推奨であり、個々のホスティング構成で効果を実測したものではありません。具体的な遮断設定をコピーして一律適用するのではなく、担当者に確認してください。

すでに7.1.4になっているサイトは、今回の修正が適用された状態の確認を進めます。それでも、修正前に侵入された可能性や、別の問題による改変までは、版番号から否定できません。公式の侵害時FAQも、症状・時刻・直前の操作の記録とホスティング会社への確認を案内しています。

管理者向けには、WP-CLIのcore versionが版確認、core verify-checksumsが公式ファイルとの整合確認に利用できます。本記事ではコマンドを実行していません。チェックサムの一致は比較対象の本体ファイルについての結果で、データベース、アップロード、プラグイン、別の追加ファイルまで正常と保証するものではありません。

暫定的なアクセス制限やWAFは、修正版の適用や調査の代わりにはなりません。更新を永続的に無効化すると、今回以外の修正も届かなくなります。更新を安全に進める短時間の作業計画、復元手段、確認担当をそろえることを優先してください。

一般のサイト利用者が、訪問先をスキャンしたり更新したりする必要はありません。自社サイトの管理を外注している場合は、担当者へ「本体の稼働版」「CVE-2026-119977への対応」「更新中の公開制御」「過去の侵害確認」の4点を問い合わせます。日常の利用者向けの周知は、確認された影響に応じて運営者が判断します。

LLMが役立つのは、複数サイトの更新記録を同じ形式にそろえ、未確認の項目を拾う作業です。自動で本番を変更させたり、資料にない情報から安全を宣言させたりしないよう、次の指示を使えます。

記録にはWordPress更新・調査確認シート（TXT）を使えます。空の記録用教材で、サーバーを調べるプログラムではありません。判断の基本は脆弱性の対象判定と修正確認を参照してください。また、PHP本体の重大脆弱性への対応は別途必要です。WordPress本体とPHPの修正状況を混同しないでください。

確認日：2026年11月4日JST。KEVと公式資料を用いた解説です。実際の攻撃、本番設定変更、WordPress更新の実機試験は行っていません。対象範囲や追加勧告に変更があれば、この記事を更新します。