wp2shellは、2026年7月に公表されたWordPress Coreの脆弱性チェーンです。WordPressを企業サイトやオウンドメディアで運用している方は、まずバージョンを確認してください。
wp2shellへの対応では、更新と侵害確認を分けて進めます。
今回注意したいのは、特定のプラグインだけの問題ではないことです。条件がそろうと、ログインしていない攻撃者が管理者アカウントを作成し、その後の操作を通じてサーバー上でコードを実行できる可能性があります。米国CISAも2026年7月21日、関連する2件のCVEを「実際の攻撃で悪用が確認された脆弱性」としてKEVカタログに追加しました。
先に結論：WordPress 6.8系は6.8.6へ、6.9系は6.9.5へ、7.0系は7.0.2へ更新してください。更新しただけで「過去に侵害されていない」とは判断できないため、脆弱な期間があったサイトではログと管理者アカウントも確認します。
wp2shellの影響を受けるWordPressバージョン
WordPressバージョン・影響・推奨対応
6.8.0〜6.8.5CVE-2026-60137の影響あり。標準構成だけで直ちに未認証RCEへ至るわけではありませんが、外部入力を渡すプラグインやテーマとの組み合わせでSQLインジェクションの危険があります。6.8.6以上へ更新
6.9.0〜6.9.42件を連鎖させたwp2shellの影響あり6.9.5以上へ更新
7.0.0〜7.0.12件を連鎖させたwp2shellの影響あり7.0.2以上へ更新
6.8未満今回の2件のCVEの対象外。ただし、古いバージョンを使い続ける安全性を意味するものではありません。サポート状況を確認し、保守計画に沿って更新
自動更新が有効でも、反映済みとは限りません。管理画面の「ダッシュボード ＞ 更新」、またはWP-CLIで実際のバージョンを確認することが大切です。
wp2shellとは何か
wp2shellは、単独の不具合名というより、WordPress Coreに存在した2つの脆弱性を組み合わせた攻撃手法の呼称です。
- CVE-2026-63030：REST APIのバッチ処理で、認可確認に使ったルート情報と実際に処理されるリクエストがずれる可能性がある問題
- CVE-2026-60137：
WP_Queryのauthor__not_inで入力値の整数化が不十分だったことによるSQLインジェクション
攻撃者は、細工したREST APIリクエストによって、本来は権限が必要な処理へ到達する足掛かりを作ります。さらにSQLインジェクションを連鎖させることで、データベースとWordPress内部の状態を悪用します。公開された検証では、未認証の2リクエストで準備と管理者作成を行い、その後にログインして悪意あるプラグインを導入することでコード実行へ至る流れが示されました。
つまり「1回のHTTPリクエストだけで即座にシェルが起動する」という説明は正確ではありません。一方で、攻撃開始時にログインが不要である点と、最終的にサイト全体の掌握へつながり得る点は、企業サイトにとって十分に深刻です。
2つの脆弱性はどのようにつながるのか
- 入口：REST APIのバッチエンドポイントへ細工したリクエストを送ります。
- 権限確認のずれ：バッチ内のルート照合結果と個々のリクエストの対応関係が崩れ、本来とは異なる条件で処理が進む可能性が生じます。
- SQLインジェクション：整数の配列であるべき
author__not_inへ不正な値を渡し、想定外のSQLを組み立てさせます。 - 管理者権限の取得：報告された攻撃チェーンでは、WordPressの内部キャッシュやREST処理を利用して管理者アカウントを作成します。
- コード実行：作成した管理者でログインし、プラグインのアップロードなど管理機能を悪用してサーバー上のコード実行へ進みます。
本記事では防御と確認に必要な範囲に絞り、再現用のペイロードや侵入手順は掲載しません。自社環境で検証する場合も、本番サイトへ攻撃リクエストを送るのではなく、バックアップから分離した検証環境を作り、正式な権限と手順のもとで実施してください。
発見から修正、実悪用確認までの経緯
- 2020年：WordPressにREST APIのバッチ処理基盤が導入されました。後年の変更と組み合わさり、今回の攻撃面の一部になります。
- WordPress 6.8：
WP_Query::author__not_inに、後にCVE-2026-60137として整理されるSQLインジェクションの問題が入りました。 - WordPress 6.9：REST APIのルート処理に、後にCVE-2026-63030となる不整合が生じ、標準構成で2件を連鎖できる条件がそろいました。
- 2026年7月の公開前：発見者はWordPressセキュリティチームへ責任ある形で報告し、修正版の準備が進められました。
- 2026年7月17日：WordPress 6.8.6、6.9.5、7.0.2が公開され、対象サイトへの強制自動更新も開始されました。
- 2026年7月20日：発見者側が「wp2shell」として技術的な調査内容を公開しました。
- 2026年7月21日：CISAがCVE-2026-63030とCVE-2026-60137をKEVカタログへ追加し、実悪用を確認した脆弱性として扱いました。
WordPressは何を修正したのか
修正は、単に特定の文字列をブロックするものではありません。WordPress Coreでは主に次の3点が変更されています。
author__not_inへ渡される値を整数のリストとして正規化し、SQLへ不正な値が混入しないようにする- REST APIのバッチ処理で、リクエストとルート照合結果の配列を常に同じ位置関係に保つ
- REST API処理中にトップレベルのREST処理へ再入する経路を制限し、内部ディスパッチを強制する
複数の層で修正しているのは、既知の攻撃チェーンを止めるだけでなく、同じ構造を利用した別の回避策も成立しにくくするためです。
自社サイトを安全に確認する方法
1. バージョンとCoreファイルを確認する
wp core version
wp core verify-checksums
チェックサムエラーが出た場合、即侵害と断定はできませんが、意図しないCoreファイルの変更がないか調査が必要です。更新作業前に、現在の状態とログを保全しておくと、その後の判断がしやすくなります。
2. 身に覚えのない管理者を確認する
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
作成日時が新しいアカウント、社内で管理されていないメールアドレス、普段使わない命名のユーザーがないかを確認します。管理画面から確認する場合も、ユーザー一覧だけでなく各アカウントのメールアドレスと登録日時まで見てください。
3. プラグインとファイル変更を確認する
wp plugin list
未承認のプラグイン、最近追加されたPHPファイル、wp-content/uploads配下の実行ファイル、テーマ内の不審な変更を確認します。侵害後に名称を偽装される場合もあるため、「見覚えのある名前か」だけでなく導入履歴とファイル差分を照合します。
4. アクセスログを確認する
/wp-json/batch/v1への不審なPOSTリクエスト、短時間に連続するREST APIアクセス、その直後のログインやプラグイン操作を時系列で確認します。GETリクエストで当該パスの応答を見るだけの簡易チェックは、脆弱性の有無を正しく判定できないため推奨しません。
RedisやMemcachedなどの永続オブジェクトキャッシュがある構成では、公開されたRCEチェーンの後半が成立しない場合があります。しかし、SQLインジェクション自体がなくなるわけではありません。「キャッシュがあるから対応不要」とは判断しないでください。
脆弱なバージョンを使っていた場合の初動対応
- 証拠を保全する：侵害の疑いがある場合は、アクセスログ、監査ログ、ファイル、データベースのスナップショットを確保します。
- 修正版へ更新する：検証済みのバックアップと復旧手順を確認したうえで、対象ブランチの修正版へ更新します。
- 侵害痕跡を調べる：管理者、プラグイン、PHPファイル、cron、外部通信、REST APIログを確認します。
- 認証情報を更新する：侵害が確認または強く疑われる場合は、WordPress、ホスティング、データベース、SSH/SFTPの認証情報とWordPress saltsをローテーションします。
- 必要に応じて専門家へ連絡する：事業影響、個人情報、複数システムへの横展開が考えられる場合は、復旧を急ぐ前にフォレンジック調査とインシデント対応を開始します。
重要なのは、「アップデート済み」と「侵害されていない」は同じではないという点です。パッチは今後の悪用を防ぎますが、すでに作成されたアカウントや設置されたバックドアを自動で削除するものではありません。
今回の事例から企業が見直すべきWordPress運用
wp2shellは、WordPressの利用そのものを否定する話ではありません。むしろ、緊急パッチが出たときに「誰が、何を基準に、どれくらいの時間で対応するか」を決めておく重要性を示しています。
- 運用中のWordPress、プラグイン、テーマ、ホスティング環境を一覧化する
- 緊急度に応じたアップデートSLAと責任者を決める
- 管理者追加、プラグイン変更、ファイル改変を監視する
- 復元テスト済みのバックアップを保持する
- 侵害を疑ったときの連絡先と初動手順を文書化する
サイトの安定運用では、更新の速さと同時に、変更後の動作確認や障害時の復旧も欠かせません。WordPressに限らず、Webシステムの保守運用、セキュリティアップデート、監視体制に不安がある場合は、AMELAのシステム開発・運用支援へご相談ください。現状の体制を整理し、必要な対応範囲と改善ロードマップをご提案します。
まとめ
wp2shellは、CVE-2026-63030とCVE-2026-60137を連鎖させ、未認証の状態から管理者権限の取得、さらにコード実行へ発展し得るWordPress Coreの脆弱性です。該当バージョンを利用している場合は、修正版への更新を最優先にしてください。そのうえで、脆弱だった期間のログ、管理者アカウント、プラグイン、ファイル変更を確認し、パッチ適用と侵害調査を分けて考えることが大切です。
参考情報
※本記事は2026年7月22日時点の公開情報に基づいています。環境ごとの構成や更新状況により、必要な対応は異なります。
