wp2shell-poc

Searchlight Cyberのwp2shellアドバイザリに関連する、認証不要のWordPress RESTバッチルート混乱SQLインジェクションの独立した概念実証です。

このリポジトリはSearchlight Cyberの公式チェッカーではありません。checkはSQLiパスを確認し、readはデータベース読み取りを実行し、shellは管理者認証情報を指定するか、最初にSQLi-to-adminブリッジを実行して、プラグインベースのコマンドシェルを開きます。

影響を受けるバージョン

Searchlight Cyberのアドバイザリは、以下のwp2shell RCE対象バージョン範囲を示しています：

動作原理

RESTバッチエンドポイント（/batch/v1）は認証不要で、1回の呼び出しで複数のサブリクエストを実行し、各サブリクエストが個別に検証され、パーミッションチェックされることを前提としています。

serve_batch_request_v1()は2つの並列配列（$matches（各サブリクエストの一致したハンドラ）と$validation（各サブリクエストの検証結果））を構築し、ディスパッチ時に両方を同じオフセットでインデックスします。パスがwp_parse_url()に失敗したサブリクエストは$validationに追加されますが、$matchesには追加されないため、配列が同期しなくなり、サブリクエストが別のサブリクエストのハンドラの下でディスパッチされます。これがルート混乱です。

このPoCはプリミティブを2回ネストします：

1. POST /wp/v2/postsリクエストでrequestsボディを持つものが、バッチハンドラ自身の下でディスパッチされます。投稿リクエストとして検証されたため、そのrequestsリストはバッチスキーマに対してチェックされず、そのサブリクエストはGETを使用できるため、メソッド許可リストがバイパスされます。
2. その内部バッチ内で、GET /wp/v2/posts/999999アイテムルートリクエストが、author_exclude、orderby、per_pageなどの投稿コレクションクエリパラメータを運びます。999999 IDは存在する必要はなく、コレクション専用パラメータを検証しないアイテムルートにマッチするための可能性の低い投稿IDです。その後、デシンクにより同じリクエストがposts get_items()の下でディスパッチされ、author_excludeがWP_Queryのauthor__not_inクエリ変数にマッピングされ、脆弱なビルドがそれをSQLに文字列として補間します。

その結果、認証前に到達可能なブール型および時間ベースのブラインドSQLインジェクションが実現します。このPoCには、SQLi-to-adminチェーンで使用されるUNION偽装投稿プリミティブも含まれています。

ここで実装されているRCEパスは次のとおりです：

1. UNIONで偽のwp_posts行を使用して、投稿コレクションを通じて攻撃者が制御するコンテンツをレンダリングします。レンダリングブリッジは、SQLi readがget_items()に到達するために使用するのと同じルートである/wp/v2/posts/999999アイテムルートソースを使用します。
2. そのレンダリングを使用して、WordPressに実際のoEmbedキャッシュ投稿を作成させます。
3. それらの実際のキャッシュ投稿IDをSQLiを通じて復元します。
4. 1つのポイズンバッチリクエストで、それらのIDをカスタマイザ変更セット、ナビゲーションアイテム、リクエストフック形状として再解釈します。
5. 同じリクエストをPOST /wp/v2/usersに到達させ、生成された管理者を作成します。
6. その生成された管理者としてログインし、プラグインアップロード動作を使用してコマンドを実行します。

手順1〜5は認証前です。コマンド実行ステップは認証済みの管理者プラグインアップロードです。

要件

Python 3.8以上と標準ライブラリ。サードパーティの依存関係はありません。

使用方法

リポジトリディレクトリから実行します：

./wp2shell.py <command> <url> [options]

または、pip install .を実行してwp2shellコマンドをPATHに追加します。

check — 非破壊的脆弱性チェック

最初にパッシブなWordPressマーカーと公開バージョンヒントを表示し、次に良性のバッチマーカープローブを送信します。脆弱なバッチ実装は、ルート混乱マーカーパターンparse_path_failed、block_cannot_read、rest_batch_not_allowedを含むHTTP 207を返します。

マーカープローブはWordPressコア修正に基づいています。不正な///リクエストはparse_path_failedを生成します。/wp/v2/postsリクエストはバッチ許可スペーサーとして機能します。/wp/v2/block-renderer/...ルートはバッチ許可されていませんが、匿名でそのハンドラに到達するとblock_cannot_readを返します。/batch/v1はrest_batch_not_allowedを提供します。脆弱なビルドでは、パースエラーによりバッチハンドラ配列が同期しなくなり、スペーサーリクエストがブロックレンダラーハンドラの下でディスパッチされます。修正済みビルドでは配列が同期しているため、この正確な3つすべてのパターンは細工されたプローブでは出現しません。

デフォルトでは、checkはそこで停止し、SQLiペイロードを送信しません。アクティブなSQLi確認も必要な場合は、--confirm-sqliを使用します。確認は最初にUNION読み取りプリミティブを試み、UNIONリフレクションが利用できない場合はペアリングタイミングプローブにフォールバックします。

これらのシグナルは独立しています。バージョンヒントは単なるヒントであり、マーカーパターンはルート混乱を示し、--confirm-sqliはペイロードがデータベースに到達したことを示します。WAFがペイロードをブロックする可能性があるため、確認が失敗してもバグがないとは証明されません。

./wp2shell.py check http://target
./wp2shell.py check targets.txt          # scan every URL in the file

read — SQLインジェクションによるデータ抽出

./wp2shell.py read http://target                      # server fingerprint
./wp2shell.py read http://target --preset users       # user logins and password hashes
./wp2shell.py read http://target --query "SELECT @@version"

デフォルトの抽出方法は--technique autoで、以下の順序で利用可能なメソッドを試みます：

1. union — UNIONを介して偽のWP_Post行を偽造し、REST応答からそのタイトルを||HEX(value)||として読み戻します。ペイロードは同じ/wp/v2/posts/999999ソースルートを使用し、orderby=noneとper_page=500を指定するため、偽の行はレンダリングされた投稿として残ります。値ごとに1リクエスト。
2. error — ターゲットがMySQLエラーを反映する場合（例：WP_DEBUG_DISPLAYオン）、EXTRACTVALUE/UPDATEXMLでリクエストあたり約15バイトを漏洩します。
3. blind — ブール型二分探索、文字あたり約8リクエスト。投稿コレクションのX-WP-Totalヘッダーを真偽シグナルとして読み取り、反映された値を必要としません。

--technique union|error|blindで1つを強制します。これらの読み取りパスはデータベース行を書き込みません。

shell — コマンド実行

--userと--passwordを指定すると、shellは指定された管理者認証情報でログインし、WordPressのプラグインアップロード動作を使用します。

認証情報がない場合、shellは最初に事前認証SQLi-to-adminブリッジを実行し、生成された管理者としてログインし、その後プラグインシェルをアップロードします。

./wp2shell.py shell http://target --user admin --password '<recovered>' --cmd id
./wp2shell.py shell http://target --user admin --password '<recovered>' -i   # interactive shell
./wp2shell.py shell http://target --cmd id                                   # pre-auth bridge
./wp2shell.py shell http://target -i                                         # pre-auth interactive

shellはプラグインのウェブシェルをアップロードし（ランダムパスと実行ごとのトークンでロック）、そのパスを表示します。アップロードされたウェブシェルは自動的に削除されます。事前認証ブリッジが管理者を作成した場合、その生成されたアカウントはシェルセッション終了後に自動的に削除されます。

オプション

修正方法

WordPress 7.0.2にアップデートするか、サイトが6.9ブランチの場合は6.9.5にアップデートしてください。それまでは、エッジで/wp-json/batch/v1とrest_route=/batch/v1クエリパラメータの両方をブロックするか、rest_pre_dispatchフィルタを介してバッチエンドポイントに認証を要求してください。

法的注意事項

許可されたセキュリティテストのみに使用してください。あなたが所有する、またはテストする明示的な書面による許可を得たシステムに対してのみ使用してください。保証は一切提供されず、誤用に対する責任も負いません。

参考文献

• WordPress 7.0.2リリースのお知らせ — https://wordpress.org/news/2026/07/wordpress-7-0-2-release/
• Searchlight Cyber wp2shellアドバイザリ — https://slcyber.io/research-center/wp2shell-pre-authentication-rce-in-wordpress-core/
• sergiointel/wp2shell-poc SQLi-to-adminブリッジ — https://github.com/sergiointel/wp2shell-poc