CVE-2026-119977は、WordPressコアの更新処理を突いて、ログインしていない攻撃者がサーバー上でコードを動かせる脆弱性です。影響は4.7〜7.1.3と幅広く、米CISAは2026年11月3日に悪用を確認した脆弱性の一覧へ加えました。この記事では、系列ごとの修正版、更新のやり方で危険度が変わる理由、wp-content/upgradeを塞ぐWebサーバーの設定、アクセスログと残ったファイルの確認手順を、11月4日時点の一次情報で整理します。
まとめ：先にupgradeフォルダを塞ぎ、同じ系列の修正版へ上げてから痕跡を確認
狙われるのは、コアの更新が走っているわずかな時間です。展開中の新しいファイルが、Webから届く決まった場所に置かれることが原因でした。修正版は7.1.4、7.0.8、6.9.11など、4.7系までのすべての系列に出ています。
対応は3段です。Webサーバーでwp-content/upgradeへのアクセスを拒否し、同じ系列の修正版へ上げ、アクセスログとサーバー内に痕跡が無いかを確かめます。修正版への更新そのものが古いコードで動くため、遮断を先に入れる順番には理由があるのです。複数のサイトの更新と点検を社内で回しきれない場合は、WordPress保守・メンテナンスで更新作業と点検を受け付けています。
CVE-2026-119977の概要：影響する4.7〜7.1.3と系列ごとの修正版
最初に、どの版が影響を受け、どこまで上げれば直るのかを確定させます。数字は11月4日にNVD、GitHubのアドバイザリ、CISAのカタログから取得したものです。
NVDとKEVの登録内容：CVSS 8.1・CWE-367・11月6日の対応期限
NVDのCVE-2026-119977は10月31日に公開されました。採点はWordfenceによるCVSS 3.1の8.1（High）で、攻撃にログインも利用者の操作も要りません。ただし攻撃の難しさは「高」です。弱点の種類はCWE-367、確認した時点と使う時点の間に状態が変わる競合の問題に分類されています。
CISAのKEVカタログへの追加は11月3日で、米国の行政機関には11月6日までの対応を求めています。Security NEXTの11月4日の記事によると、Wordfenceは直近24時間で1万3000件を超える攻撃を自社製品で止めました。探す動きが実際に出ている脆弱性です。
7.1.4・7.0.8・6.9.11など系列別の修正版と4.6以前の扱い
WordPressのセキュリティアドバイザリ（GHSA-4w3m-c66w-69mg）は、系列ごとに影響範囲と修正版を並べています。主な系列は次のとおりです。
| 系列 | 影響を受ける版 | 修正版 |
|---|---|---|
| 7.1系 | 7.1.0〜7.1.3 | 7.1.4 |
| 7.0系 | 7.0.0〜7.0.7 | 7.0.8 |
| 6.9系 | 6.9.0〜6.9.10 | 6.9.11 |
| 6.8系 | 6.8.0〜6.8.11 | 6.8.12 |
| 6.7系 | 6.7.0〜6.7.10 | 6.7.11 |
| 6.5系 | 6.5.0〜6.5.13 | 6.5.14 |
| 4.7系 | 4.7.0〜4.7.38 | 4.7.39 |
| 4.6以前 | 対象外の扱い | 修正なし |
表に無い系列も、4.7系までは同じ形で修正版があります。7.1.4の告知は10月28日付で、旧系列への修正は好意として出すものだと書いています。4.6以前には修正が無く、この先も出ません。
WordPressの評価はLowでWordfenceは8.1：重大度が割れる理由
同じ脆弱性でも、WordPress自身のアドバイザリは重大度をlowとしています。成立には更新中の短い時間を当てる必要があり、いつ更新が走るかを外から知るのは簡単ではないからです。Wordfenceの8.1は、条件がそろえば認証なしでサーバーを乗っ取れる結果の重さを数えています。
運用の判断はKEVに合わせます。悪用が観測された時点で、成立の難しさは優先度を下げる理由になりません。lowの表示だけを見て、次の定期作業まで待つのは誤りです。
更新処理のどこが狙われるのか：wp-content/upgradeの作業フォルダの仕組み
攻撃手順の詳細は公表されていません。ここでは、アドバイザリの説明と、7.1.3と7.1.4のソースの差分から読み取れる範囲に絞ります。
コア一式を展開する作業フォルダがWebから届く場所にあった問題
コアを更新するとき、WordPressはダウンロードした圧縮ファイルをwp-content/upgradeの中へ展開し、そこから本番のファイルへ上書きします。GHSAの説明では、完全なパッケージを使う更新で、Webから届くupgradeフォルダの中の予測できる場所へ新しいファイルを置いていました。展開が終わってから片付けるまでの間に攻撃者が先回りすると、コードの実行まで届きます。
展開されたコピーには、初期設定用のインストーラーも含まれます。NVDの参照リンクにwp-admin/setup-config.phpの該当行が挙がっており、Wordfenceの登録名も「Staged Installer」です。本番の設定ファイルを持たない作業用のコピーで、インストーラーが動いてしまう状態だったと読めます。
7.1.4の修正3点：16文字のランダム名と配置・コピー対象の変更
7.1.3と7.1.4の差分を見ると、更新処理の修正は3つです。
- 作業フォルダの名前に16文字のランダムな文字列を付け、外から推測できなくした
- upgradeフォルダにindex.phpを置き、ディレクトリの一覧表示で作業フォルダ名が見えないようにした
- 作業フォルダから本番へファイルを写すとき、wp-config.phpを対象から外した
3つ目の修正には「作業ディレクトリに書き込まれた可能性のあるwp-config.phpは写さない」という注記が付いています。7.1.3までは、作業用のコピーで作られた設定ファイルが本番へ上書きされうる作りだったと読めます。痕跡の確認でwp-config.phpの中身まで見るのは、このためです。
差分パッケージと完全パッケージ：更新の仕方で狙われる場面が変わる理由
アドバイザリは条件を「完全なパッケージを使う更新」に限っています。WordPressの更新には、変わったファイルだけを入れた差分パッケージもあり、どちらを使うかで危険の大きさが変わります。
同じ系列の直前の版から上げると差分パッケージになる具体的な選択条件
class-core-upgrader.phpは、差分パッケージがあり、今の版が差分の起点と一致し、コアのファイルが配布物と一致するときに限って差分を選びます。どれかが欠けると、wp-contentを除いたパッケージか完全なパッケージに切り替わります。
11月4日にWordPress.orgの更新APIへ問い合わせた結果は次のとおりです。
- 7.1.3から7.1.4、7.0.7から7.0.8、6.9.10から6.9.11：差分パッケージあり
- 6.9.10や7.0.7から7.1.4へ系列をまたぐ更新：差分パッケージなし
- 6.8.11から6.9.11へ1つ上の系列の修正版：差分パッケージなし
同じ系列の直前の版から上げる自動更新は、差分で済むのが通常です。コアファイルを書き換えたサイトや、何版も遅れているサイトは、同じ系列内でも差分を使えません。
系列をまたぐ更新とコアを改変したサイトで生じる更新中の侵害リスク
危ないのは、6.x系を7.1系へ上げるような系列またぎの更新です。完全なパッケージが展開され、しかもその処理は更新前の古いコードで動きます。7.1.4へ上げる作業そのものが、修正前の作り方で作業フォルダを置くということです。
対象を探すときは、7.1.3以前のまま止まっているサイトに加え、次に大きく版を上げる予定のサイトも数えます。wp core versionで版を、wp core verify-checksumsでコアの改変の有無を確かめれば、差分で上がれるかどうかの見当が付きます。
修正版へ上げる前に入れるwp-content/upgradeの遮断設定と確認コマンド
更新の前にWebサーバーで作業フォルダへのアクセスを止めておけば、展開中の時間を突かれても外からは届きません。WordPressの更新はファイル操作で進むので、Webからの到達を止めても更新は止まりません。
NginxとApacheでupgradeフォルダへの要求を403で返す設定例
Nginxではserverブロックに次を足します。^~を付けた前方一致は、PHPを処理する正規表現のlocationより先に決まるため、upgrade配下の.phpも実行されずに拒否されます。
# Nginx：server ブロック内に追記して設定を再読み込みする
location ^~ /wp-content/upgrade/ {
deny all;
}
# Apache：VirtualHost の設定に書ける場合
<Directory "/var/www/html/wp-content/upgrade">
Require all denied
</Directory>
# Apache：サイト直下の .htaccess しか触れない場合（WordPress の書き換え規則より前）
RewriteEngine On
RewriteRule ^wp-content/upgrade/ - [F,L]
# 反映の確認（403 が返れば遮断できている）
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/wp-content/upgrade/
設定はupgradeフォルダの中の.htaccessに書かないでください。更新のたびにWordPressがフォルダの中身を消すため、7.1.3以前では置いたファイルごと消えます。サイト直下かサーバー側の設定に置きます。
同じ系列の修正版へ上げて版と配布ファイルの一致を確かめる確認手順
遮断を入れたら、wp core updateに–minorを付けて、同じ系列の修正版だけへ上げます。6.9.10なら6.9.11、7.0.7なら7.0.8です。
# 更新前の版を記録する
wp core version
# 同じ系列の修正版だけへ上げる（系列はまたがない）
wp core update --minor
# 版が修正版になったことと、コアファイルが配布物と一致することを確かめる
wp core version
wp core verify-checksums
系列をまたぐ更新は、修正版に上げたあとで別の作業として行います。修正版の更新処理は作業フォルダ名をランダムにするため、遮断に加えて二重の守りになります。更新の順番と戻し方はWordPressのバージョンアップ手順：更新の順番・WP-CLIでの実行・失敗時の戻し方にまとめました。
侵害を受けていないかの確認：アクセスログ・作業フォルダ・wp-config.php
修正版に上がっていても、それ以前の更新の時間帯に入られていれば痕跡は残ります。公表された侵害の指標（IPアドレスやハッシュ値）は無いため、要求の場所とサーバー内の状態で判断します。
アクセスログからupgrade配下のPHPへの要求を洗い出すコマンド
通常の運用で、外からwp-content/upgradeの中のファイルを開く要求は発生しません。1件でもあれば調べる対象です。ログの場所はNginxの既定にしているので、環境に合わせて読み替えてください。
# upgrade 配下への要求を送信元・日時・パス・応答コードで集計（圧縮済みのログも読む）
zgrep -hE '"(GET|POST) /wp-content/upgrade/' /var/log/nginx/access.log* \
| awk '{print $1, $4, $7, $9}' | sort | uniq -c | sort -rn | head -50
# インストーラーへの POST は最優先で調べる
zgrep -hE 'POST /wp-content/upgrade/[^ ]*setup-config\.php' /var/log/nginx/access.log*
応答が404や403ばかりなら、探りに来たが届かなかった記録です。200が返った要求があり、その時刻がコアの更新と重なっていれば、侵害を前提に次の確認へ進みます。更新の時刻は、ログの同じ時間帯にある管理画面やWP-Cronへの要求から絞れます。
本番のwp-config.phpと管理者・残ったファイルを点検する手順
作業用のコピーで作られた設定が本番へ写された場合、データベースの接続先が書き換わります。サイトの見た目が変わらなくても、接続先が自分の設定どおりかを先に見ます。
# 本番の wp-config.php の更新日時と DB 接続先
ls -l --time-style=full-iso wp-config.php
wp config get DB_HOST
wp config get DB_NAME
# 本番以外の場所に置かれた wp-config.php と、upgrade 内の残りファイル
find . -name wp-config.php -not -path ./wp-config.php
ls -la wp-content/upgrade/
# 管理者の一覧と作成日
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp user listでは、10月以降に作られた見覚えのない管理者を探します。更新が正常に終われば作業フォルダは消えるので、upgradeの中に古い作業フォルダが残っていれば、更新が途中で止まった跡です。PHPのコードが一度でも動いたなら、Webシェルの設置まで疑い、事案前のバックアップからの復元と認証情報の入れ替えを行います。
判断：更新を急ぐ順番と系列をまたぐ大型更新を後回しにする条件
悪用が観測されている以上、修正版への更新は今週中に終えるべきです。そのうえで、どの更新を先に行い、どれを後に回すかを決めます。
旧系列に止めたサイトは系列をまたがず同じ系列の修正版を先に当てる
6.9系や7.0系で止めているサイトは、7.1系への移行と脆弱性の修正を同じ日に済ませようとしないことです。系列またぎの更新は完全なパッケージを展開するので、古い更新処理のまま窓を開けることになります。先に同じ系列の修正版を当て、7.1系への移行は検証を済ませてから別の日に行います。
ただし、旧系列に止め続けてよいわけではありません。旧系列への修正は好意で出ているもので、出し続ける約束はありません。修正版を当てた後も、7.1系への移行日は決めておきます。4.6以前のサイトは修正が無いので、更新ではなく作り直しを前提に考えます。
Webサーバーの設定を変えられない環境で保守を外へ任せる判断基準
共用サーバーでNginxの設定に触れず、.htaccessも効かない環境では、遮断を自分で入れられません。この場合は、自動更新で同じ系列の修正版が入っているかを確かめるだけにとどめ、系列をまたぐ更新は事業者の対応を確かめるまで行いません。
10サイト以上を少人数で見ていて、版の把握、遮断の設定、ログの確認を全サイトで回せないなら、自前での運用は見直す時期です。攻撃面ごとの常設の設定はWordPressセキュリティ対策：攻撃面ごとの設定とWP-CLIでの確認手順に、内製と外注の分け方はWordPress保守運用とは：作業範囲・費用相場と内製か外注かの判断基準にまとめています。
CVE-2026-119977への更新対応でよくある質問と回答
このCVEで出てきやすい疑問に、11月4日時点の一次情報の範囲で答えます。
自動更新で7.1.4になっていれば対応は終わりですか？
以後の更新は修正済みの処理で動くので、新たに狙われる心配は小さくなります。ただし、7.1.4へ上がったときの更新は7.1.3の処理で動いています。差分パッケージで上がったサイトは条件に当たりにくいものの、完全なパッケージで上がった可能性があるなら、アクセスログでupgrade配下への要求を確かめてください。遮断の設定も、次の系列またぎに備えて残しておきます。
wp2shellと同じ脆弱性ですか？
別の脆弱性です。wp2shellとは？WordPress未認証RCE（CVE-2026-63030・CVE-2026-60137）の仕組みと影響バージョン・確認手順で扱った2件は、更新のタイミングと関係なく狙える組み合わせでした。CVE-2026-119977は更新中の時間だけが狙われます。どちらも認証なしでコードの実行に至る点は同じなので、両方の修正が入った版かを確かめます。
Wordfenceなどのセキュリティプラグインで防げますか？
プラグイン型の防御は、本番のWordPressが読み込まれたときに動くのが基本です。展開中のコピーへの直接の要求では本番のプラグインが読み込まれないため、設定によっては見えません。PHPの実行前に処理を挟む設定や、Webサーバー、エッジのWAFでupgrade配下を止めるほうが確実です。
共用レンタルサーバーでも遮断の設定はできますか？
Apacheで動く共用サーバーなら、サイト直下の.htaccessに書き換え規則を足す方法が使えることが多いです。書いたあとは、upgradeフォルダのURLを開いて403が返るかを必ず確かめます。Nginxだけで動くサーバーでは利用者が設定を変えられないため、事業者のWAFの対応状況を問い合わせてください。
4.6以前のWordPressを使い続けるとどうなりますか？
このCVEの修正は4.7系までしか出ていないため、4.6以前は直す手段がありません。しかも新しい版へ上げる更新は完全なパッケージになるので、遮断を入れずに上げると更新の時間帯が狙われます。遮断を入れてから上げるか、新しい環境に作り直してデータを移すかを選びます。
関連記事
- Webシェルとは？仕組み・代表例と検知・除去の手順をTomcat・PHP・IISのコマンド例で解説：コードを実行された後に残されやすいWebシェルの見つけ方と消し方です。
- UpdraftPlus 脆弱性：UpdraftCentral接続キー流出の確認とバックドア除去・1.26.14の変更点：同じ秋に起きたWordPress周辺の事案で、侵害の確認手順が共通します。
- WordPressのバックアップ設計：WP-CLIでの取得・世代管理・復元テストの手順：事案前の世代へ戻すためのバックアップの持ち方です。
- API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：Webアプリ側で認証なしの要求を止める考え方をまとめています。
