WordPress Coreの未認証RCE「wp2shell」(CVE-2026-63030)。バッチREST APIのルート取り違えがSQLiと連鎖する機構

世界のWebサイトの基盤として広く使われるWordPressのCore本体に、認証を通さずにサーバー上でコードを実行されうる脆弱性の連鎖が見つかりました。通称はwp2shellで、中心となるのはREST APIのバッチ処理エンドポイントにあるルートの取り違えCVE-2026-63030です。これ単体ではコード実行に至りませんが、WP_QueryのSQLインジェクションCVE-2026-60137と連鎖させると、未認証の攻撃者が管理者アカウントを作成し、ログインして悪性プラグインをアップロードするところまで進みます。プラグインもテーマも追加していない既定インストールが、細工したHTTPリクエストだけで狙われる点が問題です。WordPress.orgは深刻さを踏まえ、影響を受けるサイトへ強制的な自動更新を有効化しました。

この記事は、WordPressサイトを運用する開発者や情報システムの担当者に向けて、何がどう壊れるのかという機構を、WordPress公式リリース、NVD、脆弱性リサーチをもとに冷静に整理します。攻撃を再現するペイロードや手順は示しません。事実は執筆時点(2026年7月23日)で確認できた範囲に限り、検証は自組織が管理するサイトに対してのみ行う前提です。

wp2shellが連鎖する2つの脆弱性#

wp2shellは単一の欠陥ではなく、2つの脆弱性を組み合わせた攻撃チェーンの通称です。それぞれの役割を先に押さえます。

CVE-2026-63030は、WordPress CoreのREST APIバッチ処理(WP_REST_Server::serve_batch_request_v1())にあるルートの取り違えです。NVDにはCISA-ADPの評価としてCWE-436(Interpretation Conflict、解釈の不一致)が掲載されています。この欠陥はWordPress 6.9で導入されました。発見者はAssetnote(Searchlight Cyber)のAdam Kues氏です。

CVE-2026-60137は、WP_Queryのauthor__not_inパラメータのサニタイズ不備によるSQLインジェクションです。NVDはCWE-89(SQLインジェクション)に分類しています。本来はプラグインやテーマがこのパラメータへ信頼できない入力を渡した場合に成立する欠陥で、単独では未認証の攻撃経路になりません。発見者はTF1T、dtro、haongoの各氏です。

この2件が個別に存在するだけでは、既定構成のWordPressで未認証RCEには至りません。前者がバッチ処理の認可を崩し、その回避経路から後者のSQLインジェクションに未認証で到達できるようになった点が、wp2shellが重大である理由です。

WordPress公式の7.0.2リリースは、CVE-2026-60137をSQLインジェクションの問題(報告者TF1T、dtro、haongo)、CVE-2026-63030をリモートコード実行につながるREST APIのバッチルート取り違えとSQLインジェクションの問題(報告者Adam Kues、Assetnote/Searchlight Cyber)として挙げ、影響を受けるサイトへ強制自動更新を有効化したと記載しています。

バッチREST APIでルートが取り違えられる機構#

問題の核心は、バッチエンドポイント/wp-json/batch/v1が複数のサブリクエストをどう処理するかにあります。バッチAPIは、送られてきた複数のサブリクエストをまず検証し、そのあとにまとめて実行します。この検証と実行を別々のループで回す設計が、取り違えの土台になっています。

検証のループでは、各サブリクエストのパスを解析してどのハンドラに割り当てるかを決め、割り当て結果を照合用の配列に積みます。あわせて検証の可否を検証用の配列に積みます。ここでサブリクエストのパス解析(wp_parse_url())が失敗すると、失敗を示すエラーは検証用の配列には積まれる一方、照合用の配列には積まれません。つまり2つの配列の要素数がずれます。以降のサブリクエストは、実行ループで自分より1つずれた照合結果を割り当てられ、本来とは別のハンドラで実行されます。

この取り違えが認可の回避につながるのは、WordPressのREST APIが各エンドポイントの権限チェック(permission_callback)を、割り当てられたハンドラに紐づけて実行するためです。低権限で通るように仕組んだサブリクエストで配列の位置をずらし、その直後に高権限のサブリクエストを置くと、高権限側の処理が低権限側の権限チェックのもとで走ります。攻撃者は、身元を確かめる前の段階から到達できるバッチエンドポイントを入り口に、認可の壁を素通りできます。

Rapid7の解析によれば、このバッチ処理の再帰を通じてGETに対する制限も回避され、未認証のままUNIONベースのSQLインジェクションが成立します。SQLインジェクションそのものの原理と、なぜ入力の取り扱い次第でデータベースが操作されてしまうのかは、次の記事で基礎から整理しています。

あわせて読みたい

SQLインジェクションとは何か。仕組み・攻撃手法・影響・対策を原理から徹底解説

Rapid7は、バッチAPIが検証と実行を別ループで処理し、wp_parse_url()がサブリクエストのパスで失敗するとエラーが検証用配列にのみ積まれて照合用配列に積まれず、以降のサブリクエストが誤ったハンドラで実行されると説明しています。またバッチ処理の再帰でGET制限が回避されて未認証のUNIONベースSQLインジェクションが成立し、両脆弱性がそろうとWordPress内部処理を悪用して管理者アカウントを作成し、ログインして悪性プラグインをアップロードすることでコード実行に至ると記載しています。

管理者作成からコード実行に至る流れ#

未認証のSQLインジェクションが成立すると、攻撃者はこれを足がかりに、WordPress内部の処理を連鎖させてコード実行まで進めます。Rapid7の解析では、両脆弱性がそろった環境で、WordPress内部の仕組みを連結して管理者アカウントを作成し、その資格でログインし、管理画面から悪性プラグインをアップロードしてコードを実行する、という順序が示されています。発見者のSearchlight Cyber(Assetnote)は、防御側が更新する時間を確保するため、詳細な技術情報は現時点では公開しないと表明しており、本記事でも管理者作成に至る詳細な手順やペイロードは扱いません。

プラグインのアップロードがコード実行に直結するのは、WordPressの設計上、管理者権限を持つ利用者はサーバー上でPHPコードとして動くプラグインを追加できるためです。したがって、いったん管理者を作られると、追加のプラグインという正規の機能を通じて任意のコードが動きます。管理画面を経由して置かれるWebシェルやサーバー上での不正なコード実行を防ぐ土台は、サーバー側の堅牢化にあります。最小権限や不要機能の削減といった考え方は、次の記事で整理しています。

あわせて読みたい

サーバーのハードニング基礎。最小化・最小権限・更新・設定堅牢化をCISベンチマークから学ぶ

この流れで注意したいのは、持続的オブジェクトキャッシュ(persistent object cache)を使わない既定のシングルサイト構成では、攻撃者に必要なのがサイトのHTTPエンドポイントへの到達性にほぼ限られるという点です。資格情報も、フィッシングも、脆弱なプラグインの事前導入も要りません。プラグインもテーマも入れていない素のWordPressが、公開されているというだけで攻撃対象になります。世界中で膨大な数が稼働するCMSの本体でこれが起きる重みは、影響範囲の広さそのものにあります。ただしMultisite構成では通常の管理者にプラグイン追加の権限がなく、DISALLOW_FILE_MODSを有効にした環境では管理画面からのプラグイン追加そのものが止まるため、最終段のコード実行に至る経路や被害の広がりは構成によって変わります。

なお、Tenableは、このバッチ処理の脆弱な経路が持続的オブジェクトキャッシュ(persistent object cache)を使っていない場合に到達すると整理しています。多くの既定構成はこの条件に当てはまるため緩和策として当てにはできませんが、環境によって成立性が異なりうる点は把握しておくのが妥当です。

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

影響と修正の対応は次の表のとおりです。バージョンはWordPress公式リリースとNVDの記載にもとづきます。CVE-2026-63030(全チェーンの入り口)とCVE-2026-60137(SQLインジェクション単体)で影響範囲が異なる点に注意します。

CVE-2026-63030はWordPress 6.9で導入されたため、6.8系はバッチルート取り違えの影響を受けません。ただしSQLインジェクションのCVE-2026-60137は6.8系にも及ぶため、6.8系は6.8.6へ更新して塞ぐ必要があります。7.1系はベータ段階のbeta2で両方が修正されています。

CVSSの評価は情報源によって分かれます。CVE-2026-63030について、NVDが掲載するCNA(WPScan)の値はCVSS 3.1で9.8(Critical、AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)、CISA-ADPの値は7.5(High、同ベクトルでI:N/A:N)です。CVE-2026-60137も同様に、CNAは5.9(Medium)、CISA-ADPは9.1(Critical)と食い違います。数値の高低で緊急度を判断するより、未認証で既定構成が狙われ実悪用が確認されているという事実で優先度を組み立てるのが実務的です。

NVDはCVE-2026-63030を、6.9.x(6.9.5より前)と7.0.x(7.0.2より前)に影響するREST APIバッチエンドポイントのルート取り違えとし、CVE-2026-60137のSQLインジェクションと組み合わせてSQLインジェクションとリモートコード実行に至りうると記載しています。CWE分類はCISA-ADPによるCWE-436で、CVSSはCNA(WPScan)が9.8(Critical)、CISA-ADPが7.5(High)です。

実悪用の状況とKEV収録#

wp2shellは、公開から悪用までの間隔が短い事例です。2026年7月17日に修正版6.9.5と7.0.2が公開され、同時にWordPress.orgが強制自動更新を有効化しました。修正版の公開直後から、パッチの差分をもとにした公開エクスプロイトやPoCが出回りました。

CISAは2026年7月21日にCVE-2026-63030とCVE-2026-60137の両方をKnown Exploited Vulnerabilities(KEV)カタログへ収録しました。KEVへの収録は、実際の悪用が確認された脆弱性であることを意味します。これに加え、複数のセキュリティベンダーもそれぞれの観測として実環境での悪用や公開エクスプロイトによる大規模スキャンを報告しています。既定インストールが標的になるという性質から、外部に公開されたWordPressサイトは広く影響を受けうる状況です。

KEVには米連邦政府の文民行政機関に向けた対応期限が付きますが、民間組織に同じ期限が義務づけられるわけではありません。とはいえ悪用が確認されている以上、民間にとっても緊急対応の目安として扱うのが妥当です。KEV収録やEPSSを使って対応の優先順位を組み立てる考え方は、次の記事で整理しています。

あわせて読みたい

脆弱性対応の優先順位付け。CVSSだけに頼らないEPSSとCISA KEVの使い方

Qualys ThreatPROTECTは、両CVEを連鎖させるPoCが公開され実環境で悪用されていること、両CVEがCISA KEVへ収録されたこと、影響を受ける版と修正版(6.8.6、6.9.5、7.0.2)、および暫定策として匿名REST APIアクセスの制限とWAFによる/wp-json/batch/v1および?rest_route=/batch/v1の遮断を挙げています。

運用側がとる初動#

外部に公開しているWordPressを運用している場合、悪用が確認されている以上、更新と侵害調査を並行して進めます。次の順序で手を付けます。

暫定策としてのWAF遮断は有効ですが、シグネチャの回避や別経路の存在を前提に、あくまで更新までのつなぎとして扱います。WAFに何ができて何ができないかは、次の記事で整理しています。

あわせて読みたい

WAFの役割と限界、正しい使い方。シグネチャと振る舞い、回避される前提、根本対策との補完

侵害が確認された場合の検知から封じ込め、証拠保全、復旧までの初動全体は、インシデント対応の基本を整理した次の記事も参考になります。

あわせて読みたい

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

確認チェックリスト#

対応の抜けを防ぐための確認項目を整理します。

まとめ#

wp2shellは、WordPress CoreのバッチREST APIにあるルートの取り違えCVE-2026-63030が、WP_QueryのSQLインジェクションCVE-2026-60137への未認証到達を開き、両者の連鎖で管理者作成からプラグインアップロードによるコード実行へ至る攻撃チェーンです。検証と実行を別ループで処理する設計で、パス解析の失敗が配列のずれを生み、以降のサブリクエストが誤ったハンドラで実行される点が入り口になります。全チェーンの影響は6.9.0から6.9.4と7.0.0から7.0.1で、修正版は6.9.5と7.0.2、SQLインジェクション単体は6.8.6で塞がれます。2026年7月21日にKEVへ収録され実悪用が確認されている以上、更新を軸に、更新までの間はバッチエンドポイントの遮断と匿名REST APIの制限で露出を抑え、更新前の侵害を前提にログとアカウントを点検する判断が妥当です。脆弱性の悪用にあたる検証は、許可された自組織の資産に対してのみ行います。第三者のシステムを対象にする場合は、所有者や運用者からの明示的な事前許可を得たうえで、不正アクセス禁止法などの適用法令やホスティング事業者の利用規約を守って実施します。