WordPress Core の更新ウィンドウ RCE、7.1.4 で修正 (CVE-2026-119977)

要点

• WordPress Core のアップデーターの欠陥により、未認証の攻撃者は WordPress がコア更新を展開する数秒のウィンドウ内にサーバー上でコードを実行できます。影響を受けるのは 4.7.0〜7.1.3 です。Picus Security の Umut Bayram 氏が責任ある開示を行いました。
• Wordfence の CVE レコードはこの欠陥を 8.1 High、CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H と評価し、WordPress 自身のアドバイザリは同じ競合状態を Low としています。Wordfence は 10 月 30 日までの 24 時間に 62,969 件の攻撃をブロックしました。
• 修正は 2026 年 10 月 28 日にリリースされた WordPress 7.1.4 で行われ、4.7 までのすべてのブランチにバックポートされました。侵害の報告はなく、2026 年 10 月 31 日時点で CVE は CISA の KEV(既知の悪用済み脆弱性)カタログに載っていません。
• 今すぐ 7.1.4 または利用ブランチのバックポートに更新し、その後 wp-content/upgrade 配下の PHP ファイルへのリクエストを web サーバーのログから調査してください。未修正のサイトは 7.1.4 への更新を含め、更新のたびに脆弱なウィンドウを開きます。

影響を受けるか?

未認証の攻撃には以下がすべて必要です。

• WordPress 4.7.0〜7.1.3 を、下記のいずれかのブランチで実行している。
• サイトが WordPress のアップデーターでコア更新を適用しており、完全な更新パッケージを web サーバー上の wp-content/upgrade/ に展開している。
• そのディレクトリが web からアクセス可能で(Wordfence は多くのサーバーでそうだと指摘)、そのファイルが PHP として実行される。
• 攻撃者が競り勝つ。展開からクリーンアップまでの間にステージ済みファイルへ到達する必要があり、Wordfence が実験環境で観測したこのウィンドウは数秒しか続きません。

このパスは影響を受けるすべてのバージョンで予測可能なので、4 番目の条件は知識ではなくタイミングの問題です。攻撃者にサイト上のアカウントもサイト利用者の操作も不要です。

WordPress は全 web サイトの 39.5% で使われています。W3Techs の 10 月 31 日の調査はメジャーバージョン別の分布を示しますが、修正済みのリリースと脆弱なリリースを区別していません。サイトへの影響は上の表で確認してください。

実行中の各サイトのバージョンを確認してください。コマンドラインでは:

wp core version

ない場合は、ダッシュボードの「ダッシュボード」→「更新」、または「概要」ボックスでバージョンを読み取ります。ステージングディレクトリの HTTP 応答を調べるには、自分で管理するマシンから自分のサイトに対して:

curl -s -o /dev/null -w "%{http_code}\n" https://your-site.example/wp-content/upgrade/

ディレクトリへの応答だけでは、展開された PHP ファイルにアクセスできるかは判断できません。200 は単なるインデックスページの場合もあり、403 や 404 でも個々のファイルが遮断されているとは限りません。サーバー設定を確認し、修正済みリリースを適用してください。

修正方法

各サイトをそのブランチの修正バージョン、または 7.1.4 に更新します。

1. サイトとデータベースをバックアップします。
2. ダッシュボードから更新します。「ダッシュボード」→「更新」→「今すぐ更新」です。WordPress 7.1.4 はセキュリティリリースなので、バックグラウンド自動更新対応のサイトにはリリース告知の記載どおり自動的に適用されます。
3. またはコマンドラインから更新します。

wp core update

7.0 ブランチを維持する場合は、上のコマンドの代わりに次を実行します。

wp core update --version=7.0.8

表にある利用ブランチの修正バージョンを指定してください。両方のコマンドを実行しないでください。

1. 更新後、アップデーターが自身でクリーンアップしなかった wp-content/upgrade/ 配下の残骸を削除します。

まだ更新できないサイト向けに、web 到達可能性の条件を閉じる回避策が 1 つあります。

1. web サーバー レベルでステージングディレクトリへのアクセスを拒否します。nginx では server ブロック内に:

location ^~ /wp-content/upgrade/ { return 403; }

1. Apache ではサイト設定または .htaccess に:

RedirectMatch 403 ^/wp-content/upgrade/

この回避策がカバーするのはこの CVE のみです。ステージング済みファイルへの web アクセスを遮断するため、インストーラーも他のどのステージング済み PHP ファイルも実行されません。他の欠陥に対しては何もせず、サイトが修正バージョンへ達するまで維持します。

修正済み WordPress が更新フォルダーに書き込む index.php はディレクトリ一覧の表示だけを防ぎます。ランダムな作業ディレクトリ名への直接リクエストは依然機能するため、サーバーレベルの遮断の方が強力です。

根本原因は何か?

アップデーターは、コア更新をすべて、パッケージのファイル名だけから決まる作業ディレクトリへ、web サーバーが公開するフォルダー内に展開します。 WordPress 7.1.3 では WP_Upgrader::unpack_package() が、wp-admin/includes/class-wp-upgrader.php の 378 行目で、予測不可能な要素を一切含まないパスをパッケージから構築します。

$upgrade_folder = $wp_filesystem->wp_content_dir() . 'upgrade/';
// ...
// We need a working directory - strip off any .tmp or .zip suffixes.
$working_dir = $upgrade_folder . basename( basename( $package, '.tmp' ), '.zip' );

したがって wordpress-7.1.4.zip というコア更新パッケージは wp-content/upgrade/wordpress-7.1.4 へ展開されます。これは攻撃者が更新開始前に計算できるパスです。パッケージには wp-admin/setup-config.php というインストールウィザードを含む WordPress の完全なツリーが入っています。

ウィザードがこの欠陥の後半です。setup-config.php が実行を拒むのは、自分の隣に wp-config.php が既に存在する場合だけであり、wp-admin/setup-config.php の 58〜60 行目にあります。

// Check if wp-config.php has been created.
if ( file_exists( ABSPATH . 'wp-config.php' ) ) {
    wp_die(

リリースパッケージが同梱するのは wp-config-sample.php であって wp-config.php ではないため、ステージ済みツリーはこのガードを決して起動しません。更新ウィンドウ中のステージ済みウィザードへの未認証リクエストは実行され、フォーム送信値(データベース名、ユーザー、パスワード、ホスト、テーブル接頭辞)から wp-config.php をステージングツリーへ書き込みます。WordPress 7.1.4 は次節のとおりこのチェーンの 3 つの環すべてを変えました。

どのように悪用されるか?

攻撃者は予測可能なステージングパスをステージ済みウィザードに対してポーリングし、サイトが更新を展開する瞬間の数秒の競争に勝って、ステージ済みウィザードをコード実行に変えます。公開された検証用コードはなく、Wordfence が公開したのは遮断したリクエストのパターンのみです。手順は影響を受けるソース、修正、Wordfence の説明に基づきます。

1. 攻撃者は標的がこれからインストールするバージョンのステージングパス(/wp-content/upgrade/wordpress-7.1.4/ など)を計算し、wp-admin/setup-config.php をポーリングします。Wordfence は 2 つの送信元が小さなサイト群を約 14.5 時間ポーリングし、他の送信元が多数のステージングディレクトリとバージョン名の変化形を試すのを観測しました。
2. サイトのアップデーターがパッケージを展開すると、ポーリングがステージ済みウィザードに当たり始めます。実験環境でウィンドウは数秒しか続かないため、攻撃は 1 回の細工されたリクエストではなく反復ポーリングです。
3. ステージ済みツリーに wp-config.php が存在しないため、ステージ済みウィザードは実行されます。攻撃者は自分が制御するデータベースを指す設定でフォームを完了し、ウィザードはその設定をステージングツリー内の wp-config.php に書き込みます。
4. 攻撃者は Wordfence の記述のとおり、自分のデータベースを相手にステージ済み WordPress のコピーと対話し、プラグインとテーマのアップロードを含むステージ済み管理画面を通じて PHP 実行へ進みます。
5. 別経路として、7.1.4 より前は更新のコピー処理が、作業ディレクトリからサイトのルートへ wp-content と wp-includes/version.php 以外をすべてインストールしていました。攻撃者が作業ディレクトリに書いた wp-config.php はそのままサイトのルートへコピーされます。そこで毎リクエスト実行され、本番サイトを攻撃者のデータベースへ向かわせます。
6. WordPress は更新後に作業ディレクトリを削除し、ウィンドウは閉じます。手順 5 を生き延びた設定の差し替えは残り、ステージングツリーだけに留まったものは消えます。

Wordfence の成立条件はこれらの手順と一致します。

• インストーラーファイルを含む完全パッケージの更新
• ステージングツリーへの公開された web と PHP のアクセス
• 予測可能または発見されたステージングパス
• WordPress が一時ファイルをクリーンアップする前に攻撃を完了する十分な時間

攻撃の流れは?

未認証の攻撃者がサイトの更新中に予測可能なステージングパスをポーリングし、ステージ済みインストーラーに到達して、クリーンアップ前にコード実行へ変えます。フローにおける欠落した検証は、作業ディレクトリが決して持たなかった予測不可能性です。

攻撃者に何ができるか?

競争に勝った攻撃者は、更新ウィンドウの間、WordPress プロセスのユーザーとして web サーバー上で PHP コードを実行します。7.1.4 より前のバージョンでは、ウィンドウ後も設定の差し替えを持ち越せます。攻撃にアカウントも権限もサイト利用者の操作も不要です。

WordPress セキュリティチームはこの問題を Low、Wordfence は 8.1 High と評価しています。違いは競合条件で、ベクトルは攻撃複雑度 High と記録しています。

実際の利用について分かっていることはより狭い範囲です。Wordfence は 2026 年 10 月 30 日までの 24 時間にこの欠陥を狙う 62,969 件のリクエストを遮断しました。これは試行であって侵害ではありません。Wordfence、報道、WordPress のいずれからも成功した侵害は報告されておらず、CVE は 2026 年 10 月 31 日時点で KEV カタログに載っていません。

速度がこの事件の核心です。修正公開の 2 日後には大量の攻撃試行が届き、その頃サイトはまだ 7.1.4 への移行途中でした。

なぜ修正は機能するか?

WordPress 7.1.4 は commit b625b2d49c6a「Upgrade/Install: Improve the handling of the upgrade working directory」で、このチェーンを 3 点で断ちました。

        $upgrade_folder = $wp_filesystem->wp_content_dir() . 'upgrade/';

-       // Clean up contents of upgrade directory beforehand.
+       // Clean up contents of upgrade directory beforehand, keeping its index.php.
        $upgrade_files = $wp_filesystem->dirlist( $upgrade_folder );
        if ( ! empty( $upgrade_files ) ) {
            foreach ( $upgrade_files as $file ) {
+               if ( 'index.php' === $file['name'] ) {
+                   continue;
+               }
+
                $wp_filesystem->delete( $upgrade_folder . $file['name'], true );
            }
        }

-       // We need a working directory - strip off any .tmp or .zip suffixes.
-       $working_dir = $upgrade_folder . basename( basename( $package, '.tmp' ), '.zip' );
+       /*
+        * The upgrade directory is web-served. Keep it from being listed, as core does
+        * for wp-content and its plugins and themes directories, so the name of the
+        * working directory created below cannot be discovered from a directory index.
+        */
+       if ( ! $wp_filesystem->exists( $upgrade_folder . 'index.php' ) ) {
+           $wp_filesystem->put_contents( $upgrade_folder . 'index.php', "<?php\n// Silence is golden.\n", FS_CHMOD_FILE );
+       }
+
+       // We need a working directory.
+       $working_dir = $upgrade_folder . $this->get_working_dir_name( $package );

新しい private メソッドがランダムな接尾辞を追加します。

    private function get_working_dir_name( $package ) {
        // Strip off any .tmp or .zip suffixes.
        $name = basename( basename( $package, '.tmp' ), '.zip' );

        return $name . '-' . wp_generate_password( 16, false );
    }

3 番目の変更は update-core.php にあり、コピー処理の除外リストに攻撃者が書くファイルが加わりました。

-   $skip              = array( 'wp-content', 'wp-includes/version.php' );
+   $skip              = array( 'wp-content', 'wp-includes/version.php', 'wp-config.php' );

ランダムな接尾辞は、攻撃者が事前に計算できない予測可能なパスを除去します。index.php は、ランダムな名前を発見する手段としてのディレクトリ一覧を除去します。除外リストへの追加により、ディレクトリを見つけた攻撃者であっても自作の wp-config.php をサイトのルートに置かせなくなります。

この修正はアップデーター内のこのチェーンに対して完全であり、すべてのブランチへのバックポートが同じ 3 つの変更を運びます。更新フォルダー自体への web アクセスは除去しません。だからこそ「修正方法」のサーバーレベルの遮断は、引き続き価値ある縦深防御です。

侵害されたか確認するには?

この攻撃のリクエストパターンを web サーバーのアクセスログから探します。nginx の既定のログはリクエストごとに 1 行で、パスを含みます。

# Nginx: requests to PHP files under the staging path, case-insensitive; decode encoded paths separately.
grep -iE "wp-content/upgrade/[^ ]+\.php" /var/log/nginx/access.log

Apache では自分のアクセスログのパスに置き換えます。リクエスト内のステージングパス、とりわけ setup-config.php がこの欠陥の姿です。

# Apache: any request to the staged installer, on any version name.
grep -iE "wp-content/upgrade/.*/setup-config\.php" /var/log/apache2/access.log

Wordfence は攻撃者がディレクトリやバージョン名の綴りを変化させると報告しているため、判定の前にパーセントエンコードされたパスをデコードしてください。正当なクライアントがこれらのパスを呼ぶ理由はないので、発生があれば送信元アドレスとその後を調査する価値があり、単一の一致は証拠ではなく手がかりです。次に、競争に勝った攻撃が残すものを確認します。

# Any PHP file left in the staging tree.
find wp-content/upgrade -name "*.php" | sort

// Silence is golden. を含む 1 つの index.php は、修正済み WordPress 自身がそこに書くものです。それ以外の PHP ファイル、とりわけ wp-config.php は調査すべき手がかりです。Wordfence はさらに、見知らぬ管理者アカウント、自分が入れていないプラグイン、心当たりのない PHP ファイルを探すよう助言しています。失敗に終わった攻撃は、ポーリング自体以外に痕跡を残さないことがあります。

年表

• 2026-10-28: WordPress が修正 commit b625b2d49c6a 入りの 7.1.4 をリリースし、7.0.8 から 4.7.39 まで全ブランチへ修正をバックポート。
• 2026-10-29: WordPress がアドバイザリ GHSA-4w3m-c66w-69mg を公開し、競合条件を Low と評価。Picus Security の Umut Bayram 氏をクレジット。
• 2026-10-30: The Hacker News が Wordfence の集計（24 時間に 62,969 件の攻撃遮断）を報道。侵害は報告されず。
• 2026-10-31: Wordfence により CVE-2026-119977 が公開され、CVSS v3.1 8.1 High。この日時点で CISA の KEV カタログに載らない。

よくある質問

7.1.4 への更新その最中に、自分のサイトは露出しますか?

はい、更新の数秒間は露出します。更新を実行するコードはその前にインストールされていたバージョンなので、7.1.4 への更新も依然として予測可能なパスへ展開します。その瞬間の攻撃には、すでにサイトをポーリングしている攻撃者が必要で、Wordfence が観測したのはまさにそれです。待つのではなく今すぐ更新し、変更のウィンドウの間は「修正方法」のサーバーレベルの遮断を維持してください。

古いブランチを実行していますが、7.1.4 へ飛ぶ必要がありますか?

いいえ。WordPress は修正を 4.7 までの全ブランチにバックポートしたので、7.0.8、6.9.11 など「影響を受けるか?」のブランチ表にあるすべてのバックポートが同じ 3 つの変更を運びます。ブランチ移行には独自の互換性リスクがあるため、利用ブランチのバックポートの方が小さな変更です。

WordPress と Wordfence の深刻度評価はなぜ違うのですか?

WordPress は根底にある競合条件を Low とし、Wordfence の CVE レコードは攻撃複雑度 High の 8.1 High としています。両者とも同じ未認証のコード実行への経路を述べており、Low は数秒のウィンドウを、High は勝った場合の影響を重く見ています。いずれにせよ修正は同じで、攻撃テレメトリは本物です。

Wordfence が実際に観測したのは何ですか?

Wordfence は 2026 年 10 月 30 日までの 24 時間に、この欠陥を狙う 62,969 件のリクエストを遮断しました。最大 2 つの送信元は小さなサイト群を約 14.5 時間ポーリングし、他の送信元は多数のディレクトリとバージョン名の変化形を試しました。これはファイアウォール製品が遮断した試行であって確認された侵害ではなく、被害者の報告もありません。

自動更新で十分ですか?

自動更新は修正の配布経路であり、リリース告知は、バックグラウンド更新が有効な環境ではセキュリティリリースが自動適用されると確認しています。残る露出は更新ウィンドウ自体です。更新後は本記事のログ確認を、ステージングディレクトリが web からアクセス可能な場合はサーバーレベルの遮断を組み合わせてください。

攻撃者がポーリングする前に、自社の WordPress を把握する

Ostorlab のWeb Agentic Deep Scanは、Web アプリケーションとそのフレームワークバージョンを棚卸しします。どのサイトが WordPress 4.7.0〜7.1.3 を実行しているかを把握し、次の更新ウィンドウが開く前に修正バージョンへ導いてください。

参考資料

• WordPress のセキュリティアドバイザリ GHSA-4w3m-c66w-69mg「A race condition during core updates that could lead to remote code execution」、2026 年 10 月 29 日公開、ブランチ別の修正バージョン表付き: https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-4w3m-c66w-69mg (2026 年 10 月 31 日確認)
• CVE-2026-119977 のレコード。Wordfence CNA による公開で、CVSS v3.1 8.1: https://www.cve.org/CVERecord?id=CVE-2026-119977 (2026 年 10 月 31 日確認)
• WordPress 7.1.4 のリリース告知、2026 年 10 月 28 日。更新処理の報告者として Umut Bayram 氏をクレジット: https://wordpress.org/news/2026/10/wordpress-7-1-4/ (2026 年 10 月 31 日確認)
• 修正 commit b625b2d49c6a「Upgrade/Install: Improve the handling of the upgrade working directory」、WordPress 7.1.4: https://github.com/WordPress/WordPress/commit/b625b2d49c6a (2026 年 10 月 31 日確認)
• WordPress 7.1.3 のソース。脆弱な WP_Upgrader::unpack_package() の作業ディレクトリ導出と、setup-config.php の既存設定ガード: https://raw.githubusercontent.com/WordPress/WordPress/7.1.3/wp-admin/includes/class-wp-upgrader.php および https://raw.githubusercontent.com/WordPress/WordPress/7.1.3/wp-admin/setup-config.php (2026 年 10 月 31 日確認)
• Wordfence による 7.1.4 セキュリティリリースの分析「WordPress 7.1.4 Patches Unauthenticated Upgrade-Window RCE; Exploitation Attempts Detected After Release」、2026 年 10 月 29 日: https://www.wordfence.com/blog/2026/10/wordpress-7-1-4-security-release-rce/ (2026 年 10 月 31 日確認)
• The Hacker News、「WordPress RCE Flaw Draws Nearly 63,000 Attack Attempts in Just 24 Hours」、2026 年 10 月 30 日。Wordfence の Alex Thomas 氏と遮断 62,969 件を引用: https://thehackernews.com/2026/10/wordpress-rce-flaw-draws-nearly-63000.html (2026 年 10 月 31 日確認)
• WordPress Core 4.7-7.1.3 の更新ウィンドウ RCE に関する Wordfence の脅威インテリジェンス項目: https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-core/wordpress-core-470-713-unauthenticated-upgrade-window-staged-installer-remote-code-execution (2026 年 10 月 31 日確認)
• CISA の Known Exploited Vulnerabilities カタログの JSON フィード。CVE-2026-119977 で検索: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (2026 年 10 月 31 日確認)
• W3Techs の WordPress 利用統計。全 Web サイトの 39.5% とバージョン分布: https://w3techs.com/technologies/details/cm-wordpress (2026 年 10 月 31 日確認)