WordPressの脆弱性CVE-2026-119977とは、コア更新中の作業ディレクトリを狙う未認証RCEと修正版

WordPressのコア(本体)の更新処理に、更新が走っている短い時間だけ、認証なしでサーバー上のコード実行につながる脆弱性が見つかりました。CVE-2026-119977です。影響はWordPress 4.7から7.1.3までと広く、WordPressは2026年10月28日に7.1.4と、4.7までの各ブランチの修正版を公開しました。CISAは11月3日に、実際の悪用を確認した脆弱性のカタログ(KEV)へ追加しています。

厄介なのは、脆弱な処理が「更新そのもの」の中にある点です。7.1.4へ更新するときも、ファイル一式を展開する処理は更新前の版のコードで動くため、修正を当てる時間帯そのものが狙われます。この記事は、WordPressサイトを運用する開発者や制作会社、インフラ担当に向けて、脆弱性の仕組み、ブランチ別の修正版、更新の前に入れたい遮断設定、侵害の点検手順を、WordPressの公式発表、CVEレコード、NVD、CISAのKEV、修正前後のソースコードで整理します。攻撃を再現する手順は扱いません。事実は執筆時点(2026年11月5日)で確認できた範囲に限ります。

CVE-2026-119977はコア更新の作業ディレクトリに起因する脆弱性#

WordPressは、コアを更新するときに新しい版のZIPファイルをダウンロードし、wp-content/upgrade/の下に作業ディレクトリを作って展開します。展開した一式から必要なファイルを本来の場所へコピーし、終わると作業ディレクトリを消します。CVEレコードの説明によれば、ファイル一式を使う更新(full-package)で、この作業ディレクトリの場所が推測でき、しかもWebから到達できることが原因で、未認証の攻撃者が更新の時間帯にサーバー上でコードを実行できます。

CVEの採番機関(CNA)はWordPressのセキュリティ製品を手がけるWordfenceで、CVEレコードは2026年10月31日に公開されました。発見者はUmut Bayram氏です。

NVDは11月5日の時点で分析済み(Analyzed)の状態ですが、CVSSの値はWordfenceの評価を載せています。CISAの補足情報(ADP)にあるSSVCの評価は、悪用(Exploitation)がactive、自動化のしやすさ(Automatable)がno、技術的な影響(Technical Impact)がtotalです。攻撃の難しさが高いのは、更新が動いている数秒間に要求を当てる必要があるためです。

WordPressの2026年10月28日の告知は、7.1.4がセキュリティリリースであり、更新処理の弱点が更新の時間帯にリモートコード実行につながる問題(Umut Bayram氏の報告)を含む複数の脆弱性を修正したと説明しています。修正はセキュリティ修正の対象となる全ブランチ(現在は4.7まで)へ移植されており、自動のバックグラウンド更新に対応したサイトでは更新が自動で始まるとしています。

更新の数秒間にインストーラーへ届いてしまう仕組み#

7.1.3までのソースコードを見ると、作業ディレクトリはwp-content/upgrade/の直下に、ダウンロードした一時ファイルの名前をもとに作られます。一時ファイルの名前は、パッケージのファイル名に6文字の乱数を付けたものです。upgradeディレクトリには、ディレクトリ一覧の表示を防ぐためのindex.phpも置かれていませんでした。Wordfenceは攻撃の条件として、インストーラーのファイルを含むファイル一式の更新であること、作業ディレクトリにWebとPHPの実行で到達できること、場所を推測するか見つけられること、WordPressが一時ファイルを消す前に攻撃を終えられることを挙げています。

展開された一式には、新規インストールのときに使う設定画面(wp-admin/setup-config.php)も含まれます。作業ディレクトリの中には設定ファイル(wp-config.php)がまだないため、ここへ届いた要求に対して設定画面が動いてしまいます。7.1.4の修正では、更新ファイルを本来の場所へコピーする処理に「作業ディレクトリに書き込まれた可能性があるwp-config.phpを決してコピーしない」という除外が加わりました。報道で紹介されたWordfenceの説明も、修正の一つを「作業ディレクトリに置かれた設定の危険な昇格を防ぐこと」としています。つまり、更新の途中に作業ディレクトリで作られた設定ファイルが、本番のサイトへ持ち込まれる経路が塞がれたことになります。

7.1.3と7.1.4のソースコードの差分では、class-wp-upgrader.phpに作業ディレクトリ名を推測できない形で作る関数(7.1.4で追加)と、upgradeディレクトリへindex.phpを置く処理が加わり、update-core.phpのコピー対象からwp-config.phpが除外されています。

検査と使用の時間差に起きる競合状態の一般的な仕組みと対策は、次の記事で解説しています。

あわせて読みたい

レースコンディション(競合状態)の仕組みと対策。チェックと使用の隙を原子性で塞ぐ

7.1.4への更新の最中に残る危険#

コアの更新を始めるのは、更新前にサーバーへ置かれているWordPressのコードです。7.1.3のサイトが7.1.4へ更新するとき、作業ディレクトリを作って展開する処理は7.1.3のものなので、従来どおりの名前の付け方で、index.phpのないupgradeディレクトリへ展開されます。一方、ファイルをコピーする処理(update-core.php)は、展開した新しい版のものを先に配置して読み込む作りのため、wp-config.phpをコピーしない修正はこの更新から効きます。作業ディレクトリの場所の推測と一覧からの発見を防ぐ修正が効くのは、7.1.4になった後の次の更新からです。更新の最中は、作業ディレクトリ内のインストーラーへ届く状態が残ります。

WordPressは、既存のサイトでもマイナー更新(7.1.3から7.1.4のような更新)を既定で自動適用します。多くのサイトでは、修正の公開を受けて同じ時期に自動更新が走りました。Wordfenceは修正の公開直後から悪用の試みを観測したと公表しており、報道によれば、21時間で作業ディレクトリのインストーラーを狙う要求を1万8,500件以上記録しました。攻撃者は、数秒しかない時間帯に当てるため、脆弱なパスへ繰り返し要求を送っていたとされます。Wordfenceの研究環境では、作業ディレクトリが存在するのは通常数秒だったとされています。

影響を受ける版と修正版#

CVEレコードの影響範囲は、4.7から7.1までの各ブランチで、それぞれ修正版の一つ前までです。WordPress.orgの更新APIが配布している各ブランチの最新版は次のとおりで、CVEレコードの範囲と一致しています。

WordPressが実際に保守しているのは最新版だけで、古いブランチへの移植は、あくまで更新できないサイトのための措置です。WordPressのリリース資料によれば、7.1.4はこの脆弱性を含む22件の脆弱性に対応しており、ブロックのマークアップやInteractivity APIを使った格納型XSSなどの修正と、同梱するルート証明書の更新も含まれます。古いブランチの修正版も、そのブランチが影響を受ける脆弱性をまとめて修正しています。古いブランチに留まっているサイトは、この機会に最新版への移行を計画します。4.6以前は修正の対象外です。

更新の前に/wp-content/upgrade/への要求を拒否する#

作業ディレクトリへWebから届かなければ、この攻撃は成り立ちません。コアの更新はPHPがファイルを直接書き換える処理で、HTTPで作業ディレクトリを読む必要はないため、Webからのアクセスを拒否しても更新は動きます。この設定は修正版へ更新した後も残しておいて差し支えありません。

Apacheで、サイトのルートの.htaccessを使う場合は、WordPressが書き換える「# BEGIN WordPress」と「# END WordPress」の外側に書きます。

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-content/upgrade/ - [F,L]
</IfModule>

Nginxでは、PHPを処理するlocationより優先されるよう、前方一致の優先指定(^~)で拒否します。

location ^~ /wp-content/upgrade/ {
    deny all;
}

WordPressを/blog/などのサブディレクトリに置いている場合、そのサブディレクトリの.htaccessに書くなら、照合の前にディレクトリ部分が取り除かれるため、上の書き方のままで構いません。ドキュメントルートの.htaccessに書く場合と、Nginxのlocationでは、/blog/を加えたパスにします。設定を入れたら、ブラウザやcurlで/wp-content/upgrade/の下の適当なパスへ要求し、403が返ることを確かめてから更新します。WAFやCDNで同じパスへの要求を止める方法もありますが、オリジンのサーバーへ直接届く経路が残る場合は、サーバー側の設定も入れます。

レンタルサーバーやマネージドホスティングで設定を変えられない場合は、事業者の告知を確認します。事業者が更新方式を独自に管理していたり、遮断を入れていたりすることがあります。

侵害がなかったかを点検する手順#

すでに7.1.4などの修正版になっているサイトも、修正版へ更新したときに狙われた可能性は残ります。CISAはKEVのこの項目で、フォレンジックの初期調査(forensic triage)を求める扱いにしています。次の順で点検します。

侵害を疑ったときの最初の動き方は、次の記事にまとめています。

あわせて読みたい

インシデント発生時の初動対応。最初の1時間で何をするか

チェックリスト#

まとめ#

CVE-2026-119977は、WordPressのコア更新で新しいファイル一式を展開する作業ディレクトリが、推測でき、Webから到達できる場所にあったことによる競合状態です。悪用には更新中の数秒間を狙う必要がありますが、マイナー更新の自動適用で多くのサイトが同じ時期に更新するため、待ち構える攻撃が成り立ちやすくなっています。CISAはKEVへ追加しました。

対策の中心は、7.1.4か各ブランチの修正版への更新です。まだ更新していないサイトは、先に/wp-content/upgrade/へのWebからのアクセスを拒否してから更新します。更新済みのサイトも、更新の時間帯の要求とwp-config.phpを点検します。

WordPressサイト全体の守り方は、次の記事で整理しています。

あわせて読みたい

WordPressのセキュリティ対策の基本、更新とプラグイン管理、ログイン保護、権限設定の進め方