WP2Shellとは — WordPress本体を狙う未認証リモートコード実行（Pre-Auth RCE）攻撃

対象CVE：CVE-2026-63030 / CVE-2026-60137　｜　公表：2026年7月17日（米国時間）

「WP2Shell」は、WordPress本体（Core）に存在する2つの脆弱性を組み合わせることで、
ログイン不要・プラグイン不要のデフォルト構成のまま、外部の攻撃者がサーバー上で任意のコードを実行できてしまう攻撃チェーンです。
サイトを閲覧しに来た不特定多数と同じ立場から攻撃が成立するため、影響が非常に大きい脆弱性として警戒されています。

1. WP2Shell の概要

2026年7月17日（米国時間）、WordPress は 6.8.6・6.9.5・7.0.2 をリリースし、認証不要でリモートからの任意コード実行（RCE）につながる
2つの脆弱性を修正しました。発見・報告したのは Searchlight Cyber の Adam Kues 氏です。

この2つの脆弱性は、それぞれ単体では即座に致命的とは限りません。しかし組み合わせる（チェーンする）ことで、
未認証の攻撃者が任意コード実行に到達できるようになります。この攻撃チェーン全体が「WP2Shell」と呼ばれています。

攻撃を構成する2つの脆弱性

• CVE-2026-63030（REST API バッチルート混同） ― 本来なら通らないはずの権限チェックや型チェックをバイパスできてしまう欠陥。
• CVE-2026-60137（SQLインジェクション） ― WP_Query の author__not_in パラメータ処理の不備によるSQLインジェクション。

2. どのように攻撃してくるのか（仕組み）

入口：REST API のバッチエンドポイント

攻撃の起点となるのは、WordPress REST API の /batch/v1 エンドポイントです。
これは複数のAPIリクエストを1回のHTTPリクエストにまとめて処理するための正規の機能で、標準的には次のURLで到達できます。

• POST /wp-json/batch/v1
• POST /?rest_route=/batch/v1

ステップ1：バッチルート混同で検証をすり抜ける（CVE-2026-63030）

バッチ処理の内部では、各サブリクエストの「本体」「対応するハンドラ」「検証結果」を、それぞれ別の配列で
同じ添字（インデックス）を使って管理しています。ところが、サブリクエストの1つをわざとバリデーションエラーにすると、
ハンドラの配列だけ要素が追加されず、添字がズレるという実装バグがありました。

その結果、あるサブリクエストが別のエンドポイント用のハンドラで実行されてしまい、
本来ロジック実行前に行われるはずのパラメータ存在確認・型チェック・権限チェックといった検証をバイパスできてしまいます。

ステップ2：すり抜けた先でSQLインジェクション（CVE-2026-60137）

検証をバイパスした攻撃者は、投稿取得処理 WP_Query の author__not_in（除外する投稿者IDを指定するパラメータ）へ到達します。
修正前のコードでは、値が配列の場合は整数化されるのに対し、スカラー値（単一の文字列など）の場合は整数化を通らず、
そのままSQLの NOT IN 句へ連結されていました。ここに悪意ある文字列を渡すことでSQL文の構造を改変できます。

「バッチルート混同で本来届かない入力経路をこじ開ける → SQLインジェクションを成立させる → 最終的に任意コード実行へ至る」
という流れが WP2Shell の本質です。GMO Flatt Security の検証では、標準構成でも管理者の認証情報なしにRCEが可能と判断されています。

侵入に成功した後の攻撃者の動き

実際の攻撃（Wiz Research による観測）では、バッチAPIの悪用に成功した後、次のような後続行動が確認されています。

• 悪性プラグインのアップロード（POST /wp-admin/update.php?action=upload-plugin）による永続的なバックドア設置。
• ユーザー列挙（/wp-json/wp/v2/users?context=edit）で管理者のユーザー名・メールアドレスを収集。
• ローカルファイルインクルージョン（LFI）により wp-config を狙い、DB認証情報や認証キーを窃取。
• Webシェルの設置 ― eval($_POST[...]) の一行型から、150KB級の多機能型（プラグインに偽装）まで確認されています。

3. 影響を受けるバージョン

なお 6.8系は SQLインジェクション（CVE-2026-60137）の影響は受けるものの、標準構成では外部からの入力経路が無く、
WP2Shell による未認証RCEは成立しません。とはいえ SQLインジェクションを塞ぐため、6.8.6 以上への更新は必要です。

4. 対応策

根本対策：WordPress本体を修正版へ更新する

最も確実で唯一の根本対策は、WordPress Core を修正版へ更新することです。
7.0系は 7.0.2 以上、6.9系は 6.9.5 以上、6.8系は 6.8.6 以上へ更新してください。

更新までの一時的な緩和策

すぐに更新できない事情がある場合の一時しのぎとして、次のいずれかでバッチエンドポイントへの未認証アクセスを遮断します。ただし、これらは脆弱なコードそのものを直さないため、更新の代わりにはなりません。

• WAFで遮断する ― /wp-json/batch/v1 と ?rest_route=/batch/v1 の両方の形式を遮断します。
  URLデコード・正規化後の値で判定し、_method パラメータや X-HTTP-Method-Override ヘッダによるメソッド偽装を考慮して、
  受信メソッドを限定せずにブロックすることが重要です。サブディレクトリ設置の場合はそのパスも対象に含めます。
• プラグインで未認証アクセスを禁止する ― rest_pre_dispatch フィルタを使い、
  /batch/v1 への未認証アクセスを HTTP 401 で拒否します。

侵害の有無をチェックする

自サイトが既に攻撃を受けていないか、アクセスログを確認します。少なくとも次のパスへのリクエストをチェックしてください。

• POST /wp-json/batch/v1
• POST /?rest_route=/batch/v1
• POST /（設置先）/wp-json/batch/v1（サブディレクトリ設置の場合）

5. まとめ

参考情報：

• WordPressの深刻度「緊急」脆弱性 wp2shell の概要と対応指針 — GMO Flatt Security
• Exploitation in the Wild of wp2shell — Wiz Blog
• WordPress 7.0.2 Release — WordPress.org

※本記事は公開情報をもとに作成した解説であり、不正確な情報が含まれる可能性があります。対応にあたっては必ず公式情報をご確認ください。

この記事の著者

丸山純一郎

Web戦略士

1998年のWeb黎明期からホームページ制作を開始。東京にてマークアップエンジニアからスタートし、テクニカル・ディレクター、Webディレクター、クリエイティブ・ディレクターとしてキャリアを積む。電通・博報堂などの広告代理店を通じたナショナルクライアント案件を多数経験。現在は新潟県長岡市を拠点に、Webストラテジストとして中小企業・個人事業主のWeb戦略を支援。SEO・広告・解析・システム開発・AI開発まで一気通貫で担当するほか、セミナー講師・専門記事の執筆も行う。

保有資格

ウェブ解析士 / GAIQ / 生成AIパスポート