wp2shell（CVE-2026-63030）WordPress 脆弱性｜7.0.2で修正、今の更新先と確認手順

WordPress Core の認証不要 RCE「wp2shell」（CVE-2026-63030）は、2026年7月17日（米国時間）のセキュリティリリース WordPress 7.0.2 で修正されました。REST API のバッチ処理の欠陥と WP_Query の SQL インジェクション（CVE-2026-60137）が連鎖し、ログインもプラグインも要らずにコード実行に届く WordPress 脆弱性です。CISA は7月21日に2件とも KEV（悪用が確認された脆弱性の一覧）に登録しました。その後も修正は続いており、2026年10月19日時点の更新先は 7.0.2 ではありません。

取り込んだソフトウェアの欠陥を体系的に押さえるなら、サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説が全体像です。本記事は WordPress コアの修正を、自分の環境で確かめる部分に絞ります。

wp2shell（CVE-2026-63030）の時系列

日付は米国時間の公表日です。各行の出典は末尾の参照ソースにあります。

公表時に詳細が伏せられていても、修正の差分は公開リポジトリで読めます。GitHub には PoC も公開されており、KEV への登録は公開から4日後でした。いま影響範囲の版で動いているサイトは、更新と同時に侵入の痕跡も確かめる前提で動いてください。

wp2shellで何が起きたか：REST API のバッチ経路と SQL インジェクション

SQL インジェクション単体は CVE の記述どおり「プラグインやテーマが信頼できない入力を author__not_in に渡したとき」に限られる問題でした。6.9 以降ではバッチ経路の取り違えと組み合わさって、その条件を外から満たせたため、認証なしのコード実行に届きました（GHSA の説明）。

修正は 7.0 ブランチの3つのコミットで読めます。

WordPress 脆弱性への対策：更新先は 7.0.2 ではなく各系統の最新

同じ系統の中で上げれば修正は入り、メジャー版をまたぐ必要はありません。WordPress.org が配信した強制の自動更新もサイト側の自動更新の仕組みを通ります。7.1.3 の class-wp-automatic-updater.php と class-core-upgrader.php の条件では、次の構成に自動更新は当たりません。

・AUTOMATIC_UPDATER_DISABLED か DISALLOW_FILE_MODS が true
・WP_AUTO_UPDATE_CORE が false（フィルターで許していない場合）
・Web サーバーのユーザーが WordPress のファイルを書き換えられない
・WordPress のディレクトリや親ディレクトリが .git・.svn などの管理下にある

更新までのつなぎ：未ログインのバッチ API を止める

Searchlight Cyber は、更新できない場合に匿名のバッチ API を止めるよう案内し、WAF なら /wp-json/batch/v1 と ?rest_route=/batch/v1 の両方を塞ぐよう書いています。ただし 2026年10月19日に 6.9.4 で試すと、この2つの文字列だけを見る Apache のルール（.htaccess）は、URL エンコードした値・大文字の経路・index.php を前に付けた経路の要求を通し、どれもバッチの経路に届きました。WAF で塞ぐなら、表記を変えた要求も止まるかまで確かめてください。

WordPress の中で、経路を解釈した後に断る方法もあります。wp-content/mu-plugins/ に置く1ファイルです（当サイトが書いた最小の例）。

<?php
// 未ログインの /batch/v1 を、URL の書き方によらず WordPress の中で断る（更新までのつなぎ）
add_filter( 'rest_pre_dispatch', function ( $result, $server, $request ) {
	$route = strtolower( '/' . trim( $request->get_route(), '/' ) );
	if ( str_starts_with( $route, '/batch/v1' ) && ! is_user_logged_in() ) {
		return new WP_Error( 'rest_forbidden', 'Authentication is required to use the batch API.', array( 'status' => 401 ) );
	}
	return $result;
}, 99, 3 );

6.9.4 に置くと、上の表記の違いを含む7通りの POST と OPTIONS がすべて401になりました。ログイン中の管理者からのバッチ要求は207で通り、ブロックエディタは使えます。どちらの方法も修正版への更新の代わりにはなりません。

Docker で動かしている場合

公式イメージの起動スクリプト（docker-entrypoint.sh）は、/var/www/html に index.php か wp-includes/version.php があればコアをコピーしません。ボリュームで WordPress を残している構成では、新しいイメージに替えてもコアの版は変わりません。コンテナ内で WordPress を更新し、版を確かめてください。タグごとの現状は「影響範囲」の節にまとめました。

自システムの確認コマンド（版・修正の有無・入口・痕跡）

すべて読み取りだけの操作です。自分が管理するサイトとサーバーにだけ実行してください。

1. 版と修正のコードがあるかを見る

WordPress のドキュメントルート（wp-config.php がある場所）で実行します。

grep "wp_version =" wp-includes/version.php
grep -cF 'if ( $this->is_dispatching() ) {' wp-includes/rest-api/class-wp-rest-server.php  # CVE-2026-63030
grep -cF '$author__not_in_id_list = wp_parse_id_list(' wp-includes/class-wp-query.php       # CVE-2026-60137
grep -cF 'esc_html( $username )' wp-includes/user.php                                        # CVE-2026-64638
grep -cF '_wp_is_template_path_allowed(' wp-includes/template.php                            # CVE-2026-87902

数字が1以上なら、その修正のコードが入っています。各文字列は wordpress-develop のタグで、6.8.6・6.9.5・7.0.2 で 63030 と 60137 が、6.8.7・6.9.6・7.0.3（4.7.34 まで）で 64638 が、6.8.10・6.9.9・7.0.6・7.1.2（4.7.37 まで）で 87902 が、0 から1以上に変わることを確かめました。6.8 より前は 63030・60137 の行が0になりますが、影響の外です。

-F を外すと $ や括弧が正規表現として読まれ、結果が変わります。見ているのは修正のコードがファイルにあるかだけで、侵入の有無は分かりません。9月17日・10月6日の修正など、表の4件以外も入っているかは版で見るので、この4行だけでは安全とは言えません。

Docker の場合は、イメージとコンテナを分けて見ます（wordpress は自分のコンテナ名に置き換える）。

docker run --rm --entrypoint grep wordpress:6.9 "wp_version =" /usr/src/wordpress/wp-includes/version.php
docker exec wordpress grep "wp_version =" /var/www/html/wp-includes/version.php

1行目は 2026年10月19日に $wp_version = '6.9.4'; を返しました。実際に配信しているのは2行目のコンテナ内の版です。

2. batch/v1 の入口を見る（GET の404は判定にならない）

SITE="https://example.com"   # 自分のサイトに置き換える
curl -s -o /dev/null -w "GET     %{http_code}\n" "$SITE/?rest_route=/batch/v1"
for u in "/wp-json/batch/v1" "/?rest_route=/batch/v1"; do
  curl -s -o /dev/null -w "OPTIONS %{http_code}  $u\n" -X OPTIONS "$SITE$u"
done

GET の404は存在しない経路と同じ rest_no_route です。6.9.4 でも 7.1.3 でも区別が付きません。OPTIONS の200は「バッチの経路があり、外から届く」ことを示すだけで、修正済みでも200が返るので脆弱という判定ではありません。この確認が役に立つのは、緩和策が効いているかを見るときです。REST の namespaces 一覧にも batch は出ないため（/batch/v1 はルートとして登録される）、一覧に無いことも安全の根拠になりません。

3. 入られていないかを見る

wp2shell 固有の侵害指標（IoC）は、確かめた一次ソースには載っていません。以下は WordPress が乗っ取られたときに一般に残る痕跡の確認です（1行目は WP-CLI が要る）。

wp user list --role=administrator --fields=user_login,user_email,user_registered
find wp-content/uploads -name "*.php"
zgrep -ihE '"POST [^"]*batch(/|%2f)v1' /var/log/nginx/access.log* | awk '{print $4, $1, $9}'

ログは nginx・Apache の combined 書式を想定しています（Apache なら /var/log/apache2/access.log*）。207 はバッチが処理されたことを示しますが、ブロックエディタも batch/v1 に POST するので、編集作業の時刻と突き合わせます。ログが残っていない期間は確かめられず、それは「問題なし」ではありません。コアの改ざんは wp core verify-checksums で公式のチェックサムと照合できます。異常が出たら、ファイルを消して終わりにせず、バックアップからの復旧と、認証キー・全ユーザーのパスワードの再発行まで行ってください。

影響範囲：版ごと・Docker タグごと

6.8 系は「話題の RCE の対象ではないが、SQL インジェクションは対象」です。6.8 より前は wp2shell の影響を受けません（GHSA）。PHP の版で成立が変わるという記述は、確かめた一次ソースにはありません。

Docker Hub の公式 wordpress イメージは次のとおりでした（2026-10-19 08:29 JST。Docker Hub の API と、6.9 はコンテナ内の実測）。

docker-library/wordpress のビルド定義は、最新の系統（いまは 7.1）だけを追っています。versions.json の更新履歴は「Update latest to 7.1.3」のように latest の更新だけです。系統の番号でタグを固定していると、その系統の修正版のイメージは届きません。

自分が影響を受けるかを判定する手順の組み方は、nginx 2026年6月のCVE 3件解説｜Critical 2件は条件付き、自分が対象か判定する手順も同じ考え方です。承認や信頼境界のずれが攻撃面になる例は、GhostApproval・SymJack解説｜AIコーディング支援6種のsymlink承認ハイジャックにまとめています。

参照ソース

・GHSA-ff9f-jf42-662q — REST API batch-route confusion and SQL injection issue leading to Remote Code Execution（WordPress）
・GHSA-fpp7-x2x2-2mjf — Facilitated SQL injection in author__not_in of WP_Query（WordPress）
・WordPress 7.0.2 Release（WordPress.org・2026年7月17日）
・CVE-2026-63030（CVE Record）
・CVE-2026-60137（CVE Record）
・wp2shell: Pre Authentication RCE in WordPress Core（Searchlight Cyber）
・Known Exploited Vulnerabilities Catalog（CISA）
・WordPress 7.0.3 Release（WordPress.org・2026年8月6日）
・GHSA-7hp8-65ch-5whp — Unauthenticated path traversal in page-template resolution（CVE-2026-87902）
・WordPress 7.1.3 Maintenance and Security Release（WordPress.org・2026年10月6日）
・WordPress/wordpress-develop（修正コミットとタグ）
・docker-library/wordpress（公式イメージのビルド定義と docker-entrypoint.sh）