CVE-2026-119977 WordPress｜更新時の攻撃窓と確認手順

はじめに

2026 年 11 月 3 日、CISA は WordPress Core の脆弱性 CVE-2026-119977 を Known Exploited Vulnerabilities（KEV）カタログへ追加しました。WordPress のコア更新処理中に一時展開されたファイルを悪用し、認証されていない攻撃者がサーバー上でコードを実行できる可能性がある脆弱性です。

WordPress は 2026 年 10 月 28 日に修正版の 7.1.4 を公開し、旧系列にもバックポート版を提供しています。一方で、この脆弱性は「更新中」に攻撃が成立する性質を持つため、修正版への更新が完了しただけでは、更新前や更新中に攻撃を受けていないかまでは判断できません。

本記事では、企業で WordPress を管理する担当者向けに、攻撃が成立する条件、系列ごとの修正版、更新前の公開設定の確認、更新後の侵害調査を順に整理します。なお、当ブログでは本脆弱性の実機検証を実施していません。公式情報、研究者の報告、編集上の考察を区別して記載します。

結論として、WordPress 4.7.0〜7.1.3 が影響を受け、各系列の修正版（7.1 系は 7.1.4、7.0 系は 7.0.8 など）への更新が必要です。攻撃が成立し得るのは、フルパッケージによるコア更新の展開中で、一時領域が Web から到達でき PHP が実行される場合という限られた条件です。修正版の適用を優先し、更新完了後に、修正前のバージョンで行ったコア更新の時刻前後のアクセスログとファイルを調査することを推奨します。

CVE-2026-119977 の概要と CISA KEV 登録

CVE-2026-119977 は、WordPress Core のコア更新処理における TOCTOU（Time-of-check Time-of-use）競合状態の脆弱性です。CVE の採番機関（CNA）は Wordfence で、発見者として Umut Bayram 氏がクレジットされています。

脆弱性の基本情報

CVSS の基本値は 8.1 ですが、攻撃元区分はネットワーク、攻撃条件の複雑さは「高」（AC:H）と評価されています。CISA ADP の SSVC でも、悪用は確認済み（active）である一方、自動化可能性は「no」とされています。スコアの高さだけでなく、後述する成立条件と自社の更新運用をあわせて判断することが重要です。

参考: WordPress 公式ドキュメント（Version 7.1.4）
“A race condition during core updates that could lead to remote code execution”
（コア更新中の競合状態により、リモートコード実行につながる可能性がある問題）
https://wordpress.org/documentation/wordpress-version/version-7-1-4/

CISA KEV 登録と BOD 26-04 の位置づけ

KEV カタログへの追加は、CISA がこの脆弱性について実際の悪用を確認したことを示します。ただし、KEV 登録は「すべての WordPress サイトが侵害された」ことや、個別サイトで侵害が発生したことを意味するものではありません。自社サイトが影響を受けたかどうかは、後述するログやファイルの調査で個別に判断する必要があります。

KEV エントリーの対応要件（requiredAction）では、ベンダーの指示に従った緩和策の適用に加え、CISA の BOD 26-04「Prioritizing Security Updates Based on Risk」と、その「Forensics Triage Requirements」に従うことが求められています。本エントリーは forensicTriage が「Yes」とされており、修正の適用だけでなく、侵害の有無の確認も対応範囲に含まれている点が特徴です。

BOD（Binding Operational Directive）は、米国の連邦文民行政機関（FCEB）に対応を求める指令です。2026 年 11 月 6 日という期限も BOD 26-04 に基づくもので、日本企業に法的に適用される期限ではありません。ただし、悪用が確認された脆弱性の対応優先度を判断する目安として参考になります。

WordPress 更新中に RCE が成立する条件

本脆弱性は、常時公開されている機能の欠陥ではなく、コア更新の処理中だけに生じる時間窓を突くものです。全 WordPress サイトが常時、未認証 RCE の危険にさらされているわけではありません。

攻撃の成立に必要な 4 つの条件

CVE レコードの記述と Wordfence の解説によると、攻撃の成立には次の条件がそろう必要があります。

1. WordPress Core のフルパッケージ（インストーラーを含む一式）による更新が実行される。
2. 更新用ファイルが wp-content/upgrade 配下の一時ディレクトリへ展開される。
3. 展開先のパスが予測可能（または発見可能）で、Web 経由で到達でき、PHP として実行される。
4. 攻撃者が、展開ファイルが存在する短い時間内にアクセスし、クリーンアップ前に攻撃を完了する。

参考: CVE-2026-119977（CNA: Wordfence）
“predictable, web-accessible staging paths used during full-package core upgrades”
（フルパッケージによるコア更新時に使用される、予測可能で Web からアクセス可能な一時展開パス）
https://www.cve.org/CVERecord?id=CVE-2026-119977

Wordfence は、一時展開されたコピーに WordPress のインストーラー（setup-config.php）が含まれ、攻撃者がこれを経由して PHP コードの実行に至ると説明しています。また、同社のラボ環境では、一時ディレクトリが存在したのは数秒程度だったと報告しています。攻撃手法の詳細は本記事の目的から外れるため、これ以上は扱いません。

通常時と更新処理中の違い

WordPress 7.1.3 のソースコードでは、コア更新時に wp-content/upgrade 配下へ更新パッケージを展開し、ファイルの反映後にその作業ディレクトリを削除しています。状態ごとの違いは次のとおりです。

Wordfence は修正版の公開後、一時展開されたインストーラーのパスを狙うリクエストを最初の 21 時間で 18,500 件以上記録したと報告しています（Wordfence 公式ブログ）。主要な送信元の一部は、約 14.5 時間にわたって少数のサイトへ繰り返しアクセスしており、同社は更新の時間窓を狙った挙動と分析しています。これらは同社が観測した攻撃試行の件数であり、侵害が成功した件数ではありません。

フルパッケージ更新と部分更新の違い

公式情報として確認できるのは、CVE レコードと CISA KEV の説明がいずれも「フルパッケージによるコア更新」を条件としている点です。Wordfence も、インストーラーを含むパッケージ一式（complete package）の展開を条件に挙げています。

WordPress 7.1.3 のソースコード（class-core-upgrader.php）では、更新 API が返すパッケージの種類とサイトの状態に応じて、ダウンロードするパッケージを次の順で選択しています。

• 部分パッケージ（partial）: API が提供し、再インストールではなく、現在のバージョンが API の指定と一致し、事前のファイル検査で問題がない場合
• new_bundled パッケージ: 同梱テーマなどの更新対象となるバージョンをまたぐ場合
• コンテンツなしパッケージ（no_content）: API が提供している場合
• フルパッケージ（full）: 上記のいずれにも該当しない場合

ただし、CVE レコードの「フルパッケージ」がこのうちどのパッケージ種別を指すのか、部分パッケージにインストーラーが含まれるのかは、公式資料では示されていません。また、管理画面、自動バックグラウンド更新、WP-CLI など更新経路ごとの違いも明記されていません。個々のサイトでどのパッケージが使われたかを後から特定するのは難しいため、編集上の判断として、修正前のバージョンでコア更新を実行したサイトは、攻撃が成立したと決めつけずに調査対象へ含めることを推奨します。

修正版への更新作業も調査対象になる理由

WordPress 7.1.3 のソースコードでは、更新パッケージの展開は、現在インストールされているバージョンの class-wp-upgrader.php が行い、新バージョンの update-core.php が配置されるのは展開の後です（class-core-upgrader.php）。このコード構造から、編集上の考察として、修正前のバージョンから修正版へ更新する際も、展開処理には修正前のコードが使われると考えられます。

ただし、修正前のコードが使われることと、実際に攻撃可能な状態になることは別です。攻撃が成立するには、前述の 4 条件（インストーラーを含むパッケージの展開、Web から到達できる一時領域、PHP の実行、時間窓内のアクセス）がそろう必要があります。修正版への更新で必ず攻撃可能な状態になるわけではありませんが、条件がそろう環境では時間窓が生じ得るため、自動更新ですでに修正版になっているサイトも含め、その更新時刻を調査対象とすることを推奨します。修正版の公開直後から時間窓を狙ったとみられる繰り返しアクセスが観測されたという Wordfence の報告も、この考察と矛盾しません。

なお、7.1.4 のソースコードでは、作業ディレクトリ名へのランダム文字列の付与（class-wp-upgrader.php）、wp-content/upgrade への index.php の配置、作業ディレクトリ内の wp-config.php を本番へコピーしない処理（update-core.php）が追加されています。7.1.4 以降の更新では、修正後のコードが展開処理を行います。

WordPress 7.1.4 と旧系列の影響バージョン・修正版

修正は 7.1.4 だけでなく、セキュリティ更新の対象となっている 4.7 系までのすべての系列へバックポートされています。旧系列すべてが未修正というわけではありません。

系列別の影響バージョンと修正版

影響範囲は CVE レコード（CNA: Wordfence）の記載、修正版は WordPress 公式ドキュメントの一覧に基づいて整理しました。両者の系列と番号は一致しています。

4.6 以前は CVE レコード上の影響範囲外ですが、WordPress のセキュリティ更新を受けられないため、サポート対象の系列への移行が必要です。

参考: WordPress 7.1.4 リリースアナウンス
“only the most recent version of WordPress is actively supported”
（積極的にサポートされているのは WordPress の最新バージョンのみ）
https://wordpress.org/news/2026/10/wordpress-7-1-4/

旧系列へのバックポートは、最新系列と同等の継続サポートを保証するものではありません。今回は各系列の修正版で緊急対応し、長期的には最新系列への移行計画を立てることを推奨します。

管理画面と WP-CLI でのバージョン確認

本番環境とステージング環境の両方で、実際に稼働しているバージョンを確認します。管理画面では「ダッシュボード」→「更新」の画面で、現在のバージョンと利用可能な更新を確認できます。自動バックグラウンド更新が有効なサイトは自動で更新されますが、更新が完了したかは個別に確認してください。

WP-CLI を利用できる環境では、次のコマンドでバージョンを確認できます。

wp core version --extra

あわせて、コアファイルが公式配布物と一致するかを確認する場合は、次のコマンドを使用します。WordPress.org から現在のバージョンの md5 チェックサムを取得し、インストール済みのファイルと比較します。公式ドキュメントでは、このコマンドは WordPress の読み込み前に実行されると説明されています。コアファイルのチェックサムが一致していても、プラグインやテーマ、不審な PHP ファイルまで安全であることを証明するものではありません。このコマンドはコアの整合性確認として使い、wp-content 配下を含む侵害調査は後述の項目で別に行います。

wp core verify-checksums

ロケールの異なるサイトでは --locale、特定バージョンとの比較では --version を指定します。詳細は WP-CLI の公式リファレンス（wp core version / wp core verify-checksums）を参照してください。

修正版であることが確認できても、それは「今後の更新で同じ問題が起きない」ことの確認にとどまり、過去に侵害されていないことの確認にはなりません。侵害の有無は後述の調査で判断します。

更新前に確認する Web サーバーの公開設定

まだ修正前のバージョンが残っているサイトでは、wp-content/upgrade 配下への外部アクセスを制限しておくと、修正版へ更新する際の時間窓のリスクを下げられます。ただし、アクセス制限を設定するために修正版への更新を延期することは推奨しません。環境に応じて、次のように判断します。

• Web サーバーを自社で管理でき、短時間で安全に設定と確認ができる環境では、更新前のアクセス制限を検討します。
• 共用サーバーなど設定を変更できない環境では、アクセス制限の実施を更新の前提条件にしません。
• いずれの場合も修正版への更新を優先し、更新完了後に必要なログ調査を行います。

アクセス制限はあくまで補完的な対策で、修正版への更新に代わるものではありません。WAF の導入だけで根本的に解決するわけでもない点に注意してください。

構成ごとの確認観点

WAF については、Wordfence が公式ブログで、この攻撃は WordPress を読み込まずに一時展開された PHP ファイルを直接要求すると説明し、同社ファイアウォールを Extended Protection で動作させるよう案内しています。WordPress プラグインとして動作する WAF は、設定によっては直接要求された PHP ファイルを検査できない可能性がある点を確認してください。

Apache / Nginx の設定例（未検証）

次の設定例は、Apache と Nginx の公式ドキュメントに記載されたディレクティブをもとに編集部で作成したもので、当ブログでは動作確認を行っていません。パスは環境に合わせて変更し、ステージング環境でコア更新が正常に完了することを確認してから本番へ適用してください。

Nginx では、^~ 修飾子付きの前方一致 location が最長一致した場合、正規表現の location は評価されません（ngx_http_core_module）。これにより、~ \.php$ などの PHP 処理より拒否設定を優先させます。

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

Apache 2.4 では、バーチャルホスト設定などで対象ディレクトリに Require all denied を指定します（mod_authz_core）。

<Directory "/var/www/html/wp-content/upgrade">
    Require all denied
</Directory>

注意点として、WordPress は展開前に wp-content/upgrade 配下を削除する処理を持っており、7.1.3 ではすべてのファイル、7.1.4 では index.php 以外が削除対象です（7.1.3 / 7.1.4 の class-wp-upgrader.php）。このディレクトリ内に .htaccess を置いても、更新時に削除される可能性があるとコードから読み取れます（編集上の考察）。設定は Web サーバー側の設定ファイルなど、wp-content/upgrade の外で管理することを推奨します。

また、ソースコード上、コア更新は WP_Filesystem によるファイル操作で行われ、wp-content/upgrade への HTTP アクセスを前提とした処理は確認できませんでした。ただし、これはコードを読んだうえでの考察で、ホスティング固有の仕組みやプラグインの動作までは確認していません。

設定後は、次の 2 点を両方確認します。存在しないファイルへのリクエストに HTTP 404 が返るだけでは、アクセス制限が機能していることの証明にはなりません。拒否設定がなくても、ファイルが存在しなければ 404 が返るためです。

• 検証用に配置したファイルなど、実在するファイルへの HTTP アクセスが拒否（Nginx や Apache の上記設定では 403）されること
• ステージング環境で WordPress のコア更新が正常に完了すること

ホスティング事業者に確認する事項

共用サーバーやマネージド WordPress など、Web サーバーの設定を直接変更できない環境では、次の事項を事業者に確認します。

• wp-content/upgrade 配下に Web 経由でアクセスでき、PHP が実行される構成か
• 本脆弱性に対するプラットフォーム側の緩和策（WAF ルール、パスの拒否など）の有無と適用日時
• 事業者側でコア更新を実施している場合は、その実施日時と更新後のバージョン
• アクセスログ、WAF ログの保存期間と取得方法

更新後に実施する WordPress の侵害調査

更新後は、更新前または更新中に攻撃を受けていないかを調査します。調査項目は、本脆弱性に直接関係するものと、一般的な侵害後調査の項目に分けて進めると、優先順位を付けやすくなります。

本脆弱性に直接関係する調査項目

wp-config.php を調査項目に含めたのは、7.1.4 の update-core.php に「作業ディレクトリに書き込まれた可能性のある wp-config.php をコピーしない」というコメントとともに、コピー対象からの除外処理が追加されたためです（7.1.3 の該当箇所）。この修正内容からは、修正前は一時展開先で作成された設定ファイルが更新処理で本番へ反映され得たと読み取れます（編集上の考察）。ただし、実際の攻撃でこの挙動が確認されたという公式情報や研究者の報告は、本記事の執筆時点で確認できていません。想定外の変更がないかを確かめる予防的な調査項目として扱ってください。

アクセスログの確認例です。ログのパスは環境に合わせて変更してください。ローテーション済みの圧縮ログも対象にするため zgrep を使用しています。Wordfence はディレクトリ名やバージョン名を変えた試行も観測しているため、特定のファイル名に限定せずパス全体で検索します。

zgrep -i "wp-content/upgrade" /var/log/nginx/access.log*

コア更新の完了時刻の手がかりとして、wp-includes/version.php のファイル更新日時も参考になります。更新処理は失敗時に旧バージョンを報告できるよう、このファイルを最後にコピーしています。ただし、ファイルの更新日時は変更できるため、他の記録と突き合わせて判断します。

一般的な侵害後調査の項目

本脆弱性に限らず、WordPress の侵害を確認する際の一般的な項目です。Wordfence も、想定外の管理者アカウントやプラグインの確認を案内しています。

• 新規の管理者アカウントや、既存ユーザーの権限変更（マルチサイトの場合は特権管理者も含む）
• 管理者の不審なログイン、パスワードやメールアドレスの変更など認証情報の不審な利用
• インストールした覚えのないプラグイン、テーマ、改変されたコアファイル
• WAF、CDN、ホスティング事業者のログに残る、更新時刻前後の検知・ブロック記録

更新確認とアクセスログ点検を組み合わせる考え方は、別の脆弱性を扱った『WordPress wp2shell 対応｜更新確認とアクセスログ点検の手順』とも共通します。複数の脆弱性対応をまとめて点検する場合は、あわせて参照してください。

ログを判断材料にするときの注意

アクセスログに不審なリクエストがあるだけでは侵害成功を断定できず、逆に特定のログが見つからないことも侵害がなかった証明にはなりません。修正前の展開ディレクトリはパスが予測可能なため、更新していない時間帯にも攻撃試行のリクエストが記録されることがあります。一時ファイルは更新後に削除されるため、ファイルが残っていないことだけでは判断できません。

ログの保存期間

修正版と脆弱性情報が公開され、攻撃試行が観測されている 2026 年 10 月 28 日以降のコア更新を優先的に確認します。ただし、脆弱性自体は 4.7 系から存在しているため、それ以前に修正前のバージョンでコア更新を行っている場合も、ログが残っている範囲で調査対象とします。調査期間はいたずらに広げず、更新履歴とログの保存状況から決めます。保存期間の制約で調査できなかった期間は、「過去の攻撃がなかった」とは扱わず、調査できなかった範囲として記録します。共用サーバーでは保存期間が短い場合があるため、必要なログは早めに保全します。

時刻同期とタイムゾーン

Web サーバー、WAF、CDN、ホスティングのログで、UTC と日本時間などタイムゾーンが異なる場合があります。各ログの表記を統一し、サーバーの時刻同期状態も確認したうえで比較します。

更新履歴との突き合わせ

攻撃試行が更新の時間窓と重なっているか、その時間帯の応答ステータスやその後の不審な操作があるかを確認し、優先度を判断します。時間窓と重なり、PHP ファイルへのリクエストが正常応答している場合は、詳細な調査の対象にします。

複数サイトの更新計画と復旧時の注意点

複数のサイトを管理する場合は、更新前の確認から更新後の調査までを一連の作業として計画すると、対応漏れを防ぎやすくなります。

侵害の疑いがある場合の復旧の考え方

侵害の疑いがある場合、証拠保全を考慮し、調査前に安易にバックアップを復元しないことを推奨します。復元によって、攻撃の痕跡となるファイルやログが上書きされる可能性があるためです。

まずログとファイルを保全し、社内のインシデント対応手順やセキュリティベンダー、ホスティング事業者と連携して影響範囲を確認します。復旧する場合も、侵害前の時点のバックアップであることを確認したうえで修正版を適用し、管理者パスワードやデータベースの認証情報の変更を検討します。修正前のバージョンへ切り戻した状態は脆弱性が残るため、一時的な措置として扱います。

まとめ

CVE-2026-119977 は、条件がそろったコア更新の展開中という短い時間窓に限って、未認証 RCE が成立し得る脆弱性です。修正版の適用を優先したうえで、修正前のバージョンで行った更新について侵害調査を別に実施することが重要です。

• 影響範囲は WordPress 4.7.0〜7.1.3 で、修正版は 7.1.4 と各系列のバックポート版
• KEV 登録は実際の悪用の確認であり、個別サイトの侵害を意味しません。
• BOD 26-04 の期限は米国連邦機関向けで、日本企業への法的な期限ではありません。
• 攻撃にはフルパッケージ更新や Web から到達できる展開先などの条件が必要
• アクセス制限は補完策であり、設定のために更新を遅らせないことが大切です。
• 更新後は更新時刻前後のログ、wp-config.php、管理者アカウントを調査します。
• 不審なログの有無だけでは侵害の成否を判断できません。

以上、最後までお読みいただきありがとうございました。