コンテンツへスキップ
一覧に戻る
2026/11/7

WordPress の更新中を狙う脆弱性 CVE-2026-119977：悪用の試みが続く、影響範囲と環境別の対処手順

WordPress の更新中を狙う脆弱性 CVE-2026-119977：悪用の試みが続く、影響範囲と環境別の対処手順

WordPress の更新中の隙を突く CVE-2026-119977 は 4.7〜7.1.3 が対象で、米国 CISA が悪用を確認した脆弱性のカタログに追加しました。10月28日に 7.1.4 と各系統の修正版が公開され、合計22件が修正されています。更新前の遮断、環境別の手順、日本語版と中国語版の注意点、侵害の確認方法を整理します。

シェア

要点

  • WordPress：7.1.4 か各系統の修正版へ更新してください。CVE-2026-119977 は更新中の隙を突く遠隔コード実行で、4.7〜7.1.3 が対象です
  • 悪用状況：CISA が11月3日に KEV へ追加し、Wordfence は24万件超の試行を遮断しました。11月6日時点で、具体的な侵害事例の公表は確認できていません
  • 日本語版・中国語版：日本語パッケージは同じ系統内の更新でも完全パッケージを使います。公式の簡体字中国語版の最新は 7.1 のままで、対象バージョンです
  • 更新の前に：Web サーバーで wp-content/upgrade/ への外部アクセスを遮断し、403 を確認してから更新します。すぐに設定できない場合は、更新を遅らせないでください
  • 更新の後に：バージョンを確認し、wp-content/upgrade/ の残存ファイル、アクセスログ、管理者アカウントを点検します

この記事について

2026年11月6日23時30分（日本時間）時点で、WordPress の公式発表、CVE、NVD、CISA、Wordfence と各 OS・サービスの情報を確認してまとめたものです。配布状況は時間とともに変わるため、作業の前に末尾の公式リンクで最新の情報を確認してください。

深刻度の数値は発表元によって異なります。本文では、どの機関の評価かを明記しています。

遮断ルールとコマンドは、各社の文書とソースコードをもとに整理したもので、一部は当社が作成しました。いずれも実際のサーバーでは動作を確認していません。適用後は必ず結果を確かめてください。

まず確認：自分のサイトは影響を受けるか

バージョンの確認

  • 管理画面の「ダッシュボード > 更新」で確認します
  • WP-CLI の場合：wp core version --extra
  • WP-CLI がない場合：grep "wp_version =" wp-includes/version.php
  • 1台のサーバーに多数のサイトがある場合（パスは環境に合わせて変更）：find /var/www /home -type f -path '*/wp-includes/version.php' -exec grep -H "wp_version =" {} +
  • WordPress.org の状態一覧で確認する場合（バージョン部分を変更）：curl -s https://api.wordpress.org/core/stable-check/1.0/ | grep -E '"7\.1\.3" *:'。insecure は修正前、outdated は修正済みの古い系統、latest は最新です

修正版の一覧

  • 修正版：7.1.4、7.0.8、6.9.11、6.8.12、6.7.11、6.6.11、6.5.14、6.4.14、6.3.14、6.2.15、6.1.16、6.0.18、5.9.20、5.8.19、5.7.21、5.6.23、5.5.24、5.4.25、5.3.27、5.2.30、5.1.28、5.0.31、4.9.35、4.8.34、4.7.39
  • 公開日：すべて2026年10月28日です。7.1.4 の公式記事には旧系統の修正は作業中とありますが、各系統の版のページでは同じ日に公開されています
  • 目標：WordPress が積極的にサポートするのは最新版だけです。旧系統の修正は好意によるもので、目標は 7.1.4 です
  • 4.6 以前：セキュリティ更新はありません。CVE の記録は 4.7 からですが、Picus は 2.7〜4.6 にも同じ動作があると説明しており、CVE の範囲外でも安全とは言えません

更新に使われるパッケージ

CVE と CISA は、完全パッケージでの更新を対象として説明しています。どのパッケージが使われるかは、サイトの言語と更新の種類で変わります。以下は11月6日に WordPress の更新 API へ模擬の問い合わせをした結果で、実際のサイトでの観測ではありません。

  • 日本語パッケージのサイト：同じ系統内の更新でも、ダッシュボードと自動更新の両方で日本語の完全パッケージが案内されます
  • 英語版パッケージを日本語で使うサイト：ダッシュボードは日本語の完全パッケージ、自動更新は英語の差分パッケージです
  • 英語版で同じ系統内の更新：通常は差分パッケージです。インストーラーを含まないとみられますが、中身は確認できていません。コアファイルの変更や欠落があると、ダッシュボードと WP-CLI ではより大きなパッケージに変わります
  • 系統をまたぐ更新：通常は no-content などのパッケージです。Picus はこれらも影響を受けるとしていますが、CVE は完全パッケージとだけ記しています
  • 中国語版のサイト：ダッシュボードには英語版 7.1.4 が案内されます（詳細は後述）。6.8 以前の自動更新には、各系統の修正版の中国語の完全パッケージも案内されます

差分パッケージだから安全とは考えず、どの場合でも可能なら遮断してから更新してください。

CVE-2026-119977：更新作業中の隙を突く脆弱性

何が起きたか

  • 内容：WordPress は更新時に、新しいファイルを wp-content/upgrade/ の作業フォルダーへ展開します。修正前は、この間に作業フォルダー内のインストーラーへ外部からアクセスできる場合がありました
  • 影響：認証なしでサーバー上のコードを実行されるおそれがあります。修正前は、作業フォルダーに作られた wp-config.php が本番の wp-config.php へ上書きされ、攻撃者のデータベースへ接続させられる経路がありました
  • 成立条件（Wordfence）：インストーラーを含むパッケージでの更新、作業フォルダーへの公開アクセス、パスの推測または発見、片付けられる前の完了がすべて必要です。Wordfence の検証では、機会は数秒でした
  • パスの推測：Picus の整理では、5.9〜7.1.3 はパスを予測でき、4.7〜5.8 はランダムな6文字が付くため、パスがまず漏れる必要があります
  • 更新失敗の残り：更新に失敗して作業フォルダーが残ると、時間の競争なしに狙われるおそれがあります（Imunify360）
  • 修正内容：作業フォルダー名に16文字のランダムな文字列を付け、wp-content/upgrade/index.php を残し、作業フォルダーの wp-config.php をコピーしないようにしました

修正版への更新も、最後の1回は古い更新処理で動きます。この更新の危険性については各社の見方が分かれていますが、Wordfence は延期せず早く更新するよう勧めています。

深刻度の評価が分かれる理由

  • Wordfence（CNA）：CVSS 3.1 で 8.1（High）。NVD に表示されているのもこの値です
  • WordPress：Low（CVSS の数値なし）
  • Red Hat：Important
  • CISA の SSVC：悪用は active、自動化は no、技術的な影響は total
  • 読み方：成立すれば影響は大きい一方、成立は難しいという評価の違いです。Wordfence は検証で悪用は非常に難しいとし、Patchstack も実用的とは言いにくいとしています。一方、報告者の Picus は動作する攻撃手順を構築したと述べています。ただし CISA の掲載を踏まえ、更新の優先度は下げないでください

悪用の状況（11月6日時点）

  • CISA KEV：11月3日に追加されました。米国連邦機関の対応期限は11月6日です。ランサムウェアでの使用は「不明」です
  • Wordfence の観測：10月28日から11月5日の記事の時点までに24万件超の試行を遮断し、10月30日のピークは7万4千件超でした。多くは自動の繰り返しアクセスで、遮断の件数は侵害の件数ではありません
  • 実際の被害：具体的な侵害事例を示した一次情報は確認できませんでした。CISA も攻撃の詳細を公表していません
  • 実証コード：GitHub には実証コードを名乗る公開リポジトリがありますが、動作は検証されていません。内容の分からないコードは実行しないでください
  • 日本の動き：JPCERT/CC の注意喚起はありませんが、11月5日の Weekly Report が取り上げています。IPA の注意喚起も確認できませんでした。国内の被害の公表は確認できていません

同時に修正された主な脆弱性

WordPress は 7.1.4 で合計22件を修正しました。11月6日時点で CVE が確認できたのは CVE-2026-119977 だけです。

  • GHSA-83c2-c4pc-wmp3（WordPress の評価 High）：Interactivity API の格納型 XSS とサービス妨害。寄稿者以上が必要で、6.4 以降が対象です
  • GHSA-p2r6-rwjp-phv3（Medium、Wordfence 5.3）：未公開のカスタマイザーの変更を認証なしで閲覧できます。4.9 以降が対象です
  • GHSA-9vrg-x932-q57q（Medium、Wordfence 6.4）：カスタマイザーの格納型 XSS。寄稿者以上が必要で、管理者がプレビューを開くと実行されます。5.0 以降が対象です
  • GHSA-j255-3x8q-7q7g（Medium、Wordfence 6.4）：コメントのページ送りなどのブロックの格納型 XSS。寄稿者以上が必要で、5.9 以降が対象です
  • そのほか：Categories ブロック、Image・Playlist ブロック、Script Modules、Notes、個人データ消去の画面、マルチサイトのユーザー画面などの修正があります
  • ルート証明書：同梱の証明書（composer/ca-bundle 1.6.0）も更新されました
  • Gutenberg プラグイン：24.3 以降に修正が含まれます。7.2 のベータ版は Beta 4 を使ってください

今回より前の修正にも注意が必要です。CVE-2026-87902 は 7.1.2 と各系統の修正版（7.0.6、6.9.9、6.8.10 など、4.7.37 まで）、CVE-2026-63030 は 7.0.2 と 6.9.5 で修正されました。それらの系統のより古い版は未修正で、どちらも CISA KEV に掲載されています。

特に危険な構成

  • 日本語パッケージで自動更新を使うサイト：無人の更新でも完全パッケージが使われます
  • Web サーバーで遮断できないサイト：WordPress の中で動くファイアウォールでは防げません。作業フォルダーのコピーはサイトのプラグインを読み込まないためです（Patchstack）。Wordfence のファイアウォールは Extended Protection の設定が必要で、このルールが無料版に届くのは11月27日です
  • 更新に失敗したまま放置しているサイト：作業フォルダーが残っている場合があります
  • 自動更新が止まっているサイト：修正が届かないまま、旧版にとどまります
  • 複数の人が投稿するサイト：ほかの21件の多くは寄稿者以上のアカウントが必要です

対処1：更新の前に外部アクセスを遮断する

Wordfence の執筆者は、すぐに設定できる運用者にはこの遮断を勧める一方、方法を調べるために更新を遅らせないよう注意しています。遮断は一時的な対策で、ほかの21件は修正されません。

  • nginx：server ブロックに location ^~ /wp-content/upgrade/ { return 403; } を追加し、nginx -t のあと nginx -s reload を実行します
  • Apache の仮想ホスト：次の3行を追加します（パスは環境に合わせて変更）
  • <Directory "/var/www/html/wp-content/upgrade">
  • Require all denied
  • </Directory>
  • Apache の反映：apachectl configtest のあと apachectl -k graceful を実行します
  • 共有サーバーの .htaccess：WordPress のフォルダーの .htaccess で、# BEGIN WordPress より上に次の2行を追加します
  • RewriteEngine On
  • RewriteRule ^wp-content/upgrade/ - [F]
  • OpenLiteSpeed：上の RewriteRule の形を使い、.htaccess の自動読み込みを有効にして再起動します
  • Caddy：サイトのブロックに respond /wp-content/upgrade/* 403 を追加し、sudo systemctl reload caddy を実行します
  • IIS：web.config の <denyUrlSequences> に <add sequence="/wp-content/upgrade/" /> を追加します。応答は403ではなく404で、ログに404.5と記録されます
  • Bitnami の VM：.htaccess は効かない場合があります。/opt/bitnami/apache/conf/vhosts/htaccess/wordpress-htaccess.conf に上の <Directory> の形で追加し、パスは /opt/bitnami/wordpress/wp-content/upgrade にして、sudo /opt/bitnami/ctlscript.sh restart apache を実行します
  • パスの注意：サブディレクトリにインストールしたサイトは、nginx と Caddy のルールに前のパスを足します。作業フォルダーは WP_CONTENT_DIR の下に作られるため、Bedrock は /app/upgrade/ です
  • フォルダーの中に置かない：wp-content/upgrade/ の中に .htaccess や index.php を置いても、修正前の更新処理が消してしまいます
  • 確認：curl -I https://example.com/wp-content/upgrade/probe.php を実行し、403 を確認します。Apache の <Directory> は、フォルダーがないと404になる場合があり、その結果では確認になりません。ProxyPassMatch で PHP を PHP-FPM へ渡す構成では <Directory> が効かないため、<Location "/wp-content/upgrade/">、Require all denied、</Location> を使い、サブディレクトリの場合は前のパスを足します

対処2：更新する

  1. ファイルとデータベースをバックアップします
  2. 上の遮断を設定し、結果を確認します
  3. 更新します。管理画面は「ダッシュボード > 更新」、WP-CLI は同じ系統なら wp core update --minor、最新版へなら wp core update のあと wp core update-db（マルチサイトは wp core update-db --network）です
  4. バージョンを確認します
  • WP-CLI の注意：--version と --locale を付けると完全パッケージになります。--force は新しい版を古い版へ戻す場合があるため使わないでください
  • データベース：同じ系統内の更新では、データベースの更新処理は必要ありません
  • 手動更新：公式の手順は、バックアップ、プラグインの無効化、パッケージの展開、wp-config.php と wp-content などを残した古いファイルの削除、新しいファイルのアップロード、/wp-admin/ へのアクセスです
  • PHP の最低版：7.1.4 と 7.0.8 は PHP 7.4、6.6〜6.9 系は 7.2.24、6.3〜6.5 系は 7.0、5.2〜6.2 系は 5.6.20、4.7〜5.1 系は 5.2.4 が必要です
  • 4.6 以前：古い更新処理を使わず、手動で対応版へ置き換えることを当社は勧めます
  • PHP 本体：WordPress を更新しても PHP 本体は修正されません。10月の PHP の修正はこちらの記事で整理しています

自動更新が届かないサイト

7.1.4 の公式記事は、バックグラウンド更新に対応したサイトは自動で更新されるとしていますが、強制更新には触れていません。必ず確認してください。

  • 管理画面の「ツール > サイトヘルス」で、バックグラウンド更新の結果を確認します
  • 設定を確認します：grep -nE "DISALLOW_FILE_MODS|AUTOMATIC_UPDATER_DISABLED|WP_AUTO_UPDATE_CORE|DISABLE_WP_CRON" wp-config.php
  • WordPress のフォルダーと親フォルダーに .git、.svn、.hg、.bzr があると、自動更新は止まります
  • 過去の失敗の記録を確認します：wp option get auto_core_update_failed --format=json（マルチサイトは wp site option get auto_core_update_failed --format=json）
  • DISABLE_WP_CRON を設定し、システムの cron もないサイトでは、自動更新は動きません

中国語版の注意

  • 新規インストール：https://cn.wordpress.org/latest-zh_CN.zip は 7.1 で、対象バージョンです。公開サイトには使わず、https://downloads.wordpress.org/release/wordpress-7.1.4.zip から始めて、サイトの言語で中国語を選んでください（当社の案）
  • 既存サイト：遮断のあと「ダッシュボード > 更新」から更新します。11月6日時点で API は英語版 7.1.4 を案内しています
  • ビルドがない版：7.1.1 以降、7.0.5 以降、6.9.8 以降の簡体字中国語のビルドはありません。6.8.12 以前の版にはあります
  • WP-CLI：wp core update --minor か wp core update を使い、--version=7.1.4 は付けないでください
  • チェックサム：簡体字中国語の一覧がない版は wp core verify-checksums --locale=en_US を使います。中国語版のファイルが残っていると、不一致が出る場合があります
  • 繁体字：最新のビルドは 7.0.8 で、7.1 系はありません。ただし https://tw.wordpress.org/latest-zh_TW.zip は 7.0.4 のままで対象バージョンのため、使わないでください

OS・環境別の修正版と手順

  • Debian 13：6.8.12+dfsg1-0+deb13u1（DSA-6596-1）。sudo apt update のあと sudo apt install --only-upgrade wordpress を実行し、dpkg-query -W wordpress で確認します
  • Debian forky・sid：7.1.4+dfsg1-1
  • Debian 12：6.1.9+dfsg1-0+deb12u1 は11月6日時点で未修正です。Debian 13 か、公式版の修正版へ移ることを当社は勧めます。Debian 11 以前も未修正です
  • Ubuntu：公式アーカイブの wordpress は jammy 5.8.3、noble 6.4.3、resolute 6.7.2 で、修正版は確認できませんでした。Ubuntu の CVE ページは読めず、状況は未確認です。apt-cache policy wordpress で確認し、公開サイトでは公式版の修正版へ移ることを当社は勧めます
  • Fedora：Fedora Rawhide（fc46）と Fedora 45 は安定版に 7.1.4-1 が入っています。Fedora 44 と 43 の 6.9.11-1 は11月6日時点でテスト中です。sudo dnf upgrade --refresh wordpress で届かない場合は、--enablerepo=updates-testing を付けます
  • RHEL 系（EPEL）：Red Hat は WordPress を提供していません。EPEL の修正版は11月6日時点でテスト中です。sudo dnf upgrade --refresh --enablerepo=epel-testing wordpress で更新できます
  • Arch Linux：wordpress 7.1.4-1。sudo pacman -Syu を実行します
  • Gentoo：www-apps/wordpress の 7.1.4、7.0.8、6.9.11、6.8.12、6.7.11、6.6.11、6.5.14、6.4.14 があり、いずれもテスト用のキーワードです
  • FreeBSD：www/wordpress は main が 7.1.4 ですが、2026Q4 の四半期ブランチは 7.1.2 で未修正です。VuXML に WordPress の項目がないため、pkg audit では検出できません
  • 公式 Docker イメージ：wordpress:7.1.4 と wordpress:latest が修正版です。既存のボリュームはイメージを変えても更新されないため、docker exec <コンテナ名> grep wp_version wp-includes/version.php で確認し、サイトの中で更新します。wordpress:7.0、wordpress:6.9、wordpress:6.8 は更新が止まっており、脆弱なままです
  • Bitnami のコンテナ：bitnami/wordpress:latest は 7.1.4 で、ベース OS は Photon です。Helm チャートの既定は古い版のため、イメージを明示してください。bitnamilegacy/wordpress は更新が止まっています
  • Composer・Bedrock：roots/wordpress に 7.1.4 があります。Bedrock は既定で自動更新が無効のため、composer require roots/wordpress -W のあと composer.lock が 7.1.4 以降であることを確認し、デプロイします
  • 1Panel：アプリは 7.1.4 になりましたが、ボリュームのサイトは変わらない場合があります。アプリのフォルダーで grep "wp_version =" data/wp-includes/version.php を確認し、古ければサイトの中で更新します
  • Softaculous：一覧には未修正の古い版も残っています。新規インストールでは修正版だけを選んでください
  • WP Toolkit（cPanel・Plesk）：サイトごとに版と自動更新の設定を確認します
  • AWS Lightsail：既存のインスタンスの更新は利用者の作業です。スナップショットを取り、遮断してから更新します。Bitnami の WordPress ブループリントは11月19日以降、新規では選べなくなります
  • Azure App Service：既定でマイナー更新の自動適用が有効ですが、版は wp-admin で確認してください
  • Pantheon：修正は配信済みですが、ダッシュボードの Code タブで Apply Updates を実行し、Test と Live へデプロイするまで本番に届きません
  • WP Engine：一般方針ではセキュリティ更新を早期に適用するとしていますが、7.1.4 の個別の説明は確認できませんでした
  • Kinsta・WordPress.com：今回の対応の説明は確認できませんでした。版を確認し、修正版でなければ問い合わせてください
  • Windows・macOS：サーバー用の公式パッケージはありません。brew upgrade wp-cli は CLI を更新するだけで、サイトの WordPress は更新しません

日本のレンタルサーバー

  • ConoHa WING：10月29日に告知し、10月30日にその告知を更新しました。新規インストールは 7.1.4 です。既存サイトは自動更新が有効なら順次更新され、無効なら自分で更新します。告知の「悪用の報告はない」という記述は、CISA の掲載より前のものです
  • お名前.com レンタルサーバー：10月29日に告知しました。既存サイトは自動更新が有効なら順次更新され、無効なら自分で更新します。告知の「悪用の報告はない」という記述も、CISA の掲載より前のものです
  • ロリポップ！：11月6日に確認したお知らせの一覧は10月24日までで、今回の修正より前のため、判断材料になりません
  • エックスサーバー、シンレンタルサーバー、スターサーバー、さくらのレンタルサーバ、mixhost、KAGOYA：11月6日に確認したお知らせの一覧に、今回の修正についての告知は見当たりませんでした。一覧の範囲は各社で異なり、サーバー側の対策の有無は確認できていません

事業者が対応済みと考えず、「ダッシュボード > 更新」で版を確認してください。

更新後に必ず確認すること

  • バージョン：サイトごとに修正版の一覧と照合します。自動更新が有効でも確認してください
  • 修正の反映：grep -n get_working_dir_name wp-admin/includes/class-wp-upgrader.php が1行以上出れば、修正後の更新処理です
  • PHP のキャッシュ：opcache.validate_timestamps=0 の環境で WP-CLI、パッケージ、手動で更新した場合は、PHP-FPM か Apache を再読み込みします。CLI の php -i は Web 側の設定と異なる場合があります
  • 残存ファイル：find wp-content/upgrade -name "*.php" | sort を実行します。修正後の正常な状態では、index.php だけか、何も表示されません。wp-config.php やほかの PHP ファイルがあれば調査してください
  • 残りの片付け：更新が動いていないことを確認し（core_updater.lock と auto_updater.lock が未設定）、index.php 以外を削除します。wp-content/upgrade-temp-backup/ には触れないでください
  • アクセスログ：grep -E 'wp-content/upgrade/.*\.php' /var/log/nginx/access.log* のように、作業フォルダーの PHP へのアクセスを探します。パスは環境に合わせて変更し、圧縮されたログは zgrep を使います。遮断の確認で自分が送った probe.php へのアクセスも表示されます。ログに何もなくても、安全の証明にはなりません
  • 管理者：wp user list --role=administrator --format=csv で、知らないアカウントがないか確認します
  • プラグイン：wp plugin list と wp plugin verify-checksums --all で、知らないプラグインや改ざんを確認します
  • コアファイル：wp core verify-checksums --include-root を実行します（WP-CLI 2.8.0 以降）。プラグインとアップロードのファイルは対象外です
  • データベースの接続先：grep -nE "DB_(NAME|USER|HOST)" wp-config.php で、自分のデータベースを指しているか確認します。このコマンドはパスワードを表示しません
  • 侵害が疑われる場合：サイトを隔離し、ログを保全します。信頼できるバックアップから復元し、データベース、管理者、API の認証情報と wp-config.php の鍵をすべて変更してください

公式情報（一次情報）

免責事項

本記事は2026年11月6日時点の公開情報を Two Sheep株式会社が整理したもので、各製品の動作や安全性を保証するものではありません。作業の前に、必ず各提供元の最新情報をご確認ください。記載の社名・製品名は各社の商標または登録商標です。記載の企業名は情報の出典・対象として記したもので、当社との取引関係を示すものではありません。

データセンターに設置したサーバーの再起動、コンソール作業、機器交換など、現地での作業が必要な場合は、当社のリモートハンズサービスにご相談ください。

シェア