公開2026.07.21更新2026.10.20 脆弱性・インシデント

wp2shellとは？WordPress未認証RCE（CVE-2026-63030・CVE-2026-60137）の仕組みと影響バージョン・確認手順【2026年10月】

2026年7月、WordPressコアそのものに、ログインしていない攻撃者が任意のコードを実行できる脆弱性チェーンが公表されました。通称「wp2shell」です。プラグインを一つも入れていない素のWordPressでも成立するため、影響は世界中の膨大なサイトに及びます。本記事は注意喚起では終わらせず、2つのCVEがどう連鎖するのかを技術で分解したうえで、自分のサイトが危ないかを確かめる手順、攻撃を受けた痕跡の探し方、共用サーバーでの確認点と経路遮断の副作用まで、運用の解像度で整理します。2026年7月の修正版のあとも、WordPressコアのセキュリティリリースは9月22日の7.1.2まで5回続きました。2026年10月2日時点の推奨版もあわせて示します。

まとめ：wp2shellの危険度と、いま確認すべきこと

結論から置きます。wp2shellは単一のバグではなく、REST APIのバッチ処理で起きるルート混同と、WP_QueryのSQLインジェクションを連鎖させて未認証RCEへ到達する攻撃チェーンです。WordPressは通常なら避ける強制的な自動更新でパッチを押し込み、米CISAは実際に悪用された脆弱性の一覧へ登録しました。この2つの事実だけで、放置が許されない案件だと読み取れます。最初に見るべきはコアのバージョン、次にアクセスログです。

注意したいのは、7月の修正版（6.8.6・6.9.5・7.0.2）が、2026年10月2日時点では公式の判定で「insecure（安全でない）」に変わっている点です。その後に出た7.1.2では、未認証でリモートコード実行に至るCVE-2026-87902が直り、米CISAは9月25日にこれも悪用確認済みとして登録しました。更新先は最新の7.1.2、旧ブランチに留まるなら7.0.6・6.9.9・6.8.10です。

項目	要旨
正体	2つのCVE連鎖で未認証RCE
前提条件	プラグイン不要・コア単体で成立
入口	/wp-json/batch/v1
影響版	6.9.0〜6.9.4／7.0.0〜7.0.1
wp2shellの修正版	6.8.6／6.9.5／7.0.2
推奨版（10月2日）	7.1.2（最新）
配布方法	異例の強制自動更新で配信
脅威度	PoC公開済・KEV登録済
最優先	版数確認と更新・ログ点検

wp2shellとは何か・2つの脆弱性が連鎖して未認証RCEに至る仕組み

wp2shellは、研究者が公表した攻撃チェーンに付けられた通称です。中核は2件のCVEで、どちらも単独ではコード実行に届きません。片方が認証の壁を越える入口を開け、もう片方がデータベースを操る力を与える。この組み合わせが成立したとき、攻撃者は資格情報を一切持たないまま、公開されているエンドポイントへリクエストを送るだけでサーバー上に足がかりを作れます。

押さえるべきは、これがプラグインやテーマの不具合ではなくWordPressコアの欠陥だという点です。追加の拡張を入れていない環境でも条件が揃います。だからこそ対象サイト数が桁違いに大きく、WordPress側も通常は踏み込まない強制的な更新配布へ動きました。CVEという識別子が2つ振られている事実は、独立した2つの欠陥が公式に登録されたことを示しています。

入口となるバッチ処理は、複数のREST操作を1回のリクエストにまとめて実行するための仕組みです。REST APIそのものの設計思想はRESTとはで整理していますが、wp2shellはRESTの原則の欠陥ではなく、WordPress固有のバッチ実装が抱えた処理順の取り違えに起因します。外部から滅多に呼ばれない経路であることが、後述するログ調査では逆に手がかりになります。

CVE-2026-63030とCVE-2026-60137の技術的な中身を分解する

チェーンを2段に分けて見ます。入口がCVE-2026-63030、破壊力の源がCVE-2026-60137です。開発元のアドバイザリはGHSA-ff9f-jf42-662q（63030）とGHSA-fpp7-x2x2-2mjf（60137）で、報告者はAssetnoteのAdam Kues氏らです。

CVE-2026-63030（ルート混同）：バッチAPIは、受け取った複数の操作を「検証するループ」と「実行するループ」に分けて処理していました。ここでURL解析が失敗したとき、検証結果を並べた配列と実行対象の配列がずれます。ずれた状態では、ある操作の検証結果が別の操作に適用され、本来なら匿名リクエストを弾くはずの権限チェックをすり抜けます。これが認証の壁を越える入口になりました。
CVE-2026-60137（SQLインジェクション）：WP_Queryの author__not_in パラメータは本来配列を受け取りますが、文字列がそのままSQL文へ差し込まれる経路が残っていました。通常は手前の検証で弾かれる入力が、上の配列のずれによって検証を経ずに到達します。ここでデータベースを不正に操作されます。

2段が噛み合うと、攻撃は次の順で進みます。バッチ経路で検証を回避し、SQLインジェクションで認証状態を偽装し、管理者権限のアカウントを作り、最後に細工したプラグインをアップロードしてコードを実行する。つまり最終的なコード実行は、WordPressが正規に備えている「管理者ならプラグインを入れられる」機能を踏み台にしています。侵入の入口と実行の手段が別物である点が、この攻撃チェーンの厄介なところです。

2段目のSQLインジェクションは、Webアプリの欠陥として古くから知られた型です。仕組みと防ぎ方の基礎はSQLインジェクションの解説にまとめてあり、今回のCVEも本質は同じく入力値の検証不足にあります。目新しいのは手口そのものではなく、コアの実装ミスによって検証が丸ごと迂回された点です。

wp2shellの影響バージョンと修正版・公表から悪用までの時系列

影響範囲をバージョンで整理します。フルのRCEチェーンが成立するのは6.9.0〜6.9.4と7.0.0〜7.0.1です。6.8.0〜6.8.5はSQLインジェクションの要素だけを抱えており、単独で突くには別の入力経路が要ります。修正版は6.8.6・6.9.5・7.0.2の3系統で、開発中の7.1系はベータ段階で修正が取り込まれました。WordPress 7.0.2のリリース告知は、6.8より前の版は影響を受けないとしています。

系統	状態	修正版
6.8.0〜6.8.5	SQLi要素のみ	6.8.6
6.9.0〜6.9.4	RCEチェーン成立	6.9.5
7.0.0〜7.0.1	RCEチェーン成立	7.0.2
7.1系	ベータで修正済	7.1 Beta 2以降

次に時間の流れです。入口側の欠陥は2025年12月に公開された6.9系で持ち込まれ、半年以上ものあいだ気づかれずに残っていました。2026年7月17日に修正版が緊急リリースされ、米CISAは4日後の7月21日に2件ともKEVカタログへ登録しました。IPAの7月22日の注意喚起も「脆弱性を実証するコードが公開されて」いると明記しています。

日付	できごと
2025-12-02	6.9公開・入口の欠陥が混入
2026-07-17	修正版を緊急リリース
2026-07-21	CISAのKEVカタログへ登録
2026-07-22	IPAが国内向けに注意喚起
2026-08-06	7.0.3（ログイン画面のXSS）
2026-08-12	7.0.4（投稿者権限のRCE）
2026-09-17	7.1.1（11件の修正）
2026-09-22	7.1.2（未認証RCE）
2026-09-25	CVE-2026-87902もKEV登録

この時系列が示すのは、パッチ公表がゴールではなく攻撃の号砲でもあったという現実です。修正内容が公開されれば、そこから逆算して脆弱性の在りかを突き止められます。実証コードが出回った後の未対応サイトは、狙われるかどうかではなく、いつ見つかるかの問題に変わりました。この位置づけを組織全体の脅威像と重ねたい場合は、情報セキュリティ10大脅威の文脈が参考になります。

wp2shell後も続いたコアの修正と2026年10月時点で更新すべき版

7月の修正版は、その後のリリースで追い越されています。8月6日の7.0.3はログイン画面の未認証の反射型XSS（CVE-2026-64638、条件次第でPHPコード実行に至る）など、8月12日の7.0.4はImagickとGhostscriptを使うサーバーで投稿者権限からコード実行に至るCVE-2026-65640を直しました。9月17日の7.1.1は11件のセキュリティ修正を含みます。

最も重いのは9月22日の7.1.2です。未認証の攻撃者がページテンプレートの解決処理に任意のローカルPHPファイルを読み込ませ、サーバーとテーマの条件が揃うとリモートコード実行に至るCVE-2026-87902（CVSS 3.1は8.1）が修正されました。CISAは9月25日にこれをKEVへ追加しています。修正は4.7系まで全ブランチへバックポートされ、各ブランチの最新は7.0.6・6.9.9・6.8.10です。ただし公式は「積極的にサポートするのは最新版だけ」と明記しているため、本筋は7.1.2への更新です。

wp2shellの深刻度スコアが機関ごとに割れる理由と優先度の決め方

ここは判断が分かれやすいので、はっきり言い切ります。今回のCVSSスコアは、評価した組織によって大きく違います。CVE-2026-63030は9.8とする評価もあれば7.5とする評価もあり、CVE-2026-60137に至っては5.9と9.1という真逆の読みが並びました。数字だけを見て「片方は中程度だから後回し」と判断すると、対応を誤ります。

CVE	スコアの幅	読み方
63030	7.5〜9.8	単独では認証回避まで
60137	5.9〜9.1	単独ではSQLiまで
連鎖時	実質的に緊急	未認証RCEが成立する

割れる理由は単純で、CVSSは原則として脆弱性を1件ずつ独立に評価する仕組みだからです。連鎖して初めて危険になる欠陥は、単体で切り出すと過小に見えます。逆に、連鎖後の結果まで織り込んで採点した機関のスコアは高く出ます。スコアの前提条件と評価軸についてはCVSSとはで解説していますが、複数の欠陥を組み合わせる攻撃では、この指標が本来の設計どおりには効きません。

では何を基準に優先度を決めるか。実務では次の2点で切ります。第一に、実際の悪用が観測されて公的な一覧へ登録されたかどうか。第二に、実証コードが公開されているかどうか。今回はどちらも該当し、しかも公表の翌日にコードが出ました。スコアが7.5であろうと5.9であろうと、この2条件が揃った時点で扱いは最上位です。逆に、KEV登録も実証コードもなく、内部ネットワークからしか到達できない脆弱性であれば、CVSSが9点台でも計画的な更新枠に回して構いません。数字ではなく、届くかどうかと道具があるかどうかで決める。これが判断の芯です。

自分のWordPressが影響を受けているかを5分で確認する手順

やることは3つだけです。順に潰していきます。

コアのバージョンを見る：管理画面のダッシュボードから更新画面を開けば、現在のバージョンが表示されます。6.8.6・6.9.5・7.0.2のいずれか以上であれば、wp2shellそのものは塞がっています。ただし2026年10月2日時点で安全と判定されるのは7.1.2だけで、6.8.6などは公式の判定で「insecure」です。
自動更新が本当に効いたかを疑う：強制配信の対象であっても、自動更新を明示的に無効化していた環境、ファイル権限の制約で更新に失敗した環境、長く放置されたステージングや検証用サイトは取り残されている場合があります。配信されたはずという前提は捨て、実際の版数で確かめてください。
管理外のサイトを洗い出す：1台のサーバーに複数サイトが同居している構成では、忘れられた古いWordPressが1本残っているだけで侵入口になります。ドキュメントルート配下を検索し、稼働していないサイトも含めて棚卸しします。

コマンドで確認できる環境なら、WP-CLIのほうが確実です。複数サイトをまとめて点検する場合も、シェルから回せる形にしておくと後々の作業が軽くなります。

wp core version
wp core check-update
wp core verify-checksums
wp user list --role=administrator --fields=user_login,user_registered

# 公式の判定（latest＝最新、outdated＝古いが修正済み、insecure＝安全でない）
curl -s https://api.wordpress.org/core/stable-check/1.0/ | grep -E "\"$(wp core version)\" *:"

最後の行は、WordPress.orgが公開している版ごとの判定一覧（stable-check）から自分の版を引きます。2026年10月2日に試すと、7.1.2は「latest」、6.9.9は「outdated」、7.0.2は「insecure」でした。verify-checksums は、コアのファイルが配布物と一致するかを照合するコマンドです。ここで見覚えのない差分や追加ファイルが報告されたら、単なる未更新ではなく改ざんを疑う段階に入ります。更新作業そのものの進め方と事前バックアップの考え方は、WordPress 7.0「Armstrong」の新機能・変更点と安全なアップデート手順に手順としてまとめてあります。

wp2shellの攻撃を受けていないかをログと管理画面から確認する

更新はこれからの侵入を防ぎますが、すでに入られた痕跡までは消しません。パッチ適用と並行して、過去に遡った点検が要ります。手がかりになるのは、平常時にはまず外部から呼ばれない経路への通信です。

grep -aE "batch/v1|rest_route=(/|%2F)batch" access.log

バッチ経路は、一般的なサイト運用では外部から叩かれません。ヘッドレス構成や一括編集を行うプラグインを入れていない限り、このログが並んでいること自体が調査の起点になります。到達しただけで侵害が確定するわけではないものの、該当する記録があれば以下を続けて確認してください。

管理者アカウントの棚卸し：作成した覚えのない管理者、身に覚えのない作成日時のユーザーを探します。攻撃チェーンの3段目がアカウント作成である以上、ここは最も残りやすい痕跡です。
アップロード配下のPHPファイル：wp-content/uploads は本来、画像やPDFの置き場です。ここにPHPファイルがあれば、まず正当な理由はありません。
有効化されたプラグインの一覧：見覚えのないプラグイン、名前だけそれらしい単一ファイルのプラグインを確認します。4段目のコード実行がプラグイン経由である以上、痕跡はここにも出ます。
スケジュールされた処理：定期実行の一覧に不審な処理が仕込まれていないかを見ます。再侵入の足場として残されることがあります。

痕跡が見つかった場合、パッチを当てて終わりにはできません。攻撃者が奪った権限は更新では失効しないため、管理者パスワード・データベース接続情報・認証用のシークレットキーをすべて入れ替え、侵入時期を特定したうえで健全な時点のバックアップから戻す判断が必要になります。復元の考え方と世代管理の設計はバックアップのやり方で整理しています。調査の記録を証跡として残す進め方はデジタルフォレンジックが参考になり、被害範囲の説明責任が生じる規模であれば、初動の時点で専門調査へ引き渡す前提を持っておくと安全です。

7月から9月だけでコアのセキュリティリリースが5回出たように、WordPressは更新と点検を止めた時点から危険が積み上がります。社内で追い切れない場合は、一創のWordPress保守・メンテナンスで、コア・プラグインの更新と改ざんの点検を定期作業として任せる方法があります。

共用レンタルサーバーで運用する場合の確認点と利用者が追加ですべきこと

国内の共用ホスティングでは、事業者側がWAFの防御ルールや経路の遮断を先回りして入れることがあります。ただし措置の内容と時期は事業者ごとに異なり、本記事の精査では各社の告知の一次情報までは確認できていません。契約している事業者のお知らせを自分で読み、次の3点を確かめてください。

事業者が何をしたか：自動更新を促しただけか、バッチ経路を遮断したか、WAFのルールを追加したかで、利用者に残る作業が変わります。
自分のサイトの版数：事業者が「自動更新で対応済み」と案内していても、更新の失敗や無効化で取り残される例があります。管理画面の版数を自分の目で確かめます。
遮断の解除条件：経路を塞がれた場合、外部連携が止まっていないか、更新後に元へ戻す手続きが要るかを確認します。

共通しているのは、事業者側の措置がいずれも時間稼ぎだという点です。経路の遮断もWAFも、コアが脆弱なままである事実を変えません。自社サーバーやコンテナで運用している場合は、そもそも事業者による保護が存在しません。強制自動更新の恩恵も、更新チャネルを絞っている環境では届かないことがあります。共用ホスティングより自前運用のほうが危険度が高い局面だと考えて動くのが妥当です。WordPressが外部へ開いている経路は今回のバッチだけではなく、xmlrpc.phpの役割と注意点で扱った古いインターフェースも攻撃面として残り続けます。

即時に更新できない場合の緩和策と、経路遮断がもたらす副作用の整理

検証環境の都合やプラグインの互換性で、今日いますぐコアを上げられない状況はあります。その場合に採れる手は限られており、いずれも本質的な解決ではありません。

バッチ経路の遮断：/wp-json/batch/v1 と、クエリ形式の rest_route=/batch/v1 の両方を塞ぎます。片方だけでは迂回されるため、両方を対象にする点が肝心です。
匿名でのREST参照の制限：ログインしていない状態からのREST呼び出しを絞ります。ただし外部連携や検索機能に影響が出る構成もあるため、事前の確認が要ります。
WAFによる遮断：WAFを挟んでいるなら、事業者側の防御ルールが提供済みかを確かめます。

ここで見落とされがちなのが副作用です。バッチ経路は正規の機能でもあり、ヘッドレス構成のフロントエンド、一括編集や同期を行うプラグイン、外部システムとの連携がこの経路を使っている場合、遮断すると機能が壊れます。共用サーバーで事業者が遮断した場合も、影響が出た利用者向けの解除手続きが用意されているかを確かめてください。

したがって遮断は、更新までの一時措置として入れ、更新が完了したら外す。この出口までを含めて計画してください。塞いだことを忘れたまま数か月が過ぎ、原因不明の連携エラーとして後から表面化する事故は珍しくありません。緩和策を入れた日付と解除の条件を、運用の記録として残しておくのが確実なやり方です。

パッチ後もWordPressを守り続けるための多層防御の設計指針

更新して終わりにしないための設計を示します。WordPressは狙われ続ける前提に立ち、侵入されても被害を抑える構えを組みます。

層	対策
更新の自動化	コアとプラグインの自動更新を維持
入口の防御	WAFとレート制限で不正要求を遮断
権限の最小化	管理者を絞り多要素認証を必須化
監視と検知	ファイル改ざん検知とログ監視
復旧の備え	改ざん不能なバックアップを保持
棚卸し	放置サイトと不要プラグインの削除

とりわけ効くのは、管理者権限を持つアカウントを絞り込み、そこに多要素認証（MFA）を必須にする設計です。今回の攻撃チェーンは最終段で管理者権限を作りにいきました。日常的に管理者が10人いる運用と、2人に絞ってMFAを掛けた運用では、侵害後の検知しやすさがまったく違います。加えてファイルの改ざん検知を入れておけば、外部から設置されたスクリプトを早期に捉えられます。

個別の対策が全体像のどこに効くかを押さえる出発点は、情報セキュリティの基本三要素の理解です。単発のパッチ適用と日常運用の防御は代替関係ではなく、両輪で回し続けるものだと捉えてください。表の各層を設定とコマンドに落とし込む恒久対策はWordPressセキュリティ対策：攻撃面ごとの設定とWP-CLIでの確認手順で攻撃面ごとにまとめています。

よくある質問

wp2shellはプラグインを入れていなくても危険ですか？

はい。wp2shellはWordPressコア自体の欠陥を突くため、プラグインやテーマを一切追加していない環境でも成立します。素のWordPressだから安全という理屈は通りません。

すでにパッチが自動で当たっていれば安全ですか？

wp2shellについては、6.8.6・6.9.5・7.0.2以上で塞がっています。ただし9月22日の7.1.2で未認証のリモートコード実行（CVE-2026-87902）が直っているため、2026年10月2日時点では7.1.2か、各ブランチの最新（7.0.6・6.9.9・6.8.10）まで上がっているかを確かめてください。パッチ適用より前に侵入されていた場合の痕跡は自動更新では消えないので、管理者アカウントとアップロード配下のファイルも別途点検します。