GPT-5.6 Sol Ultraが発見したWordPressの認証前SQLインジェクションからRCEへの深刻な脆弱性連鎖

wp2shellと呼ばれるWordPressの重大な脆弱性チェーンにより、認証されていない攻撃者が認証前SQLインジェクションの欠陥を悪用し、MySQLで稼働する一般的なWordPress環境でリモートコード実行(RCE)を達成できる可能性があることが明らかになりました。

パッチ管理ソリューション

セキュリティ研究者のAdam Kues氏は、WordPressのソースコードをマルチエージェントで監査する中で、GPT-5.6 Sol Ultraを使ってこの脆弱性チェーンを発見しました。

GPT-5.6 Sol UltraがWordPressの欠陥を発見

この問題は、/wp-json/batch/v1にあるREST API Batchエンドポイントに影響します。このBatch APIはWordPress 5.6で導入されたもので、単一のHTTPリクエストで複数の仮想REST要求をまとめて送信できるようにする機能です。脆弱性の原因は、class-wp-rest-server.phpファイル内で、リクエストの検証データとマッチしたルートハンドラとの間に不整合が生じていることにあります。

WordPressはバッチリクエストを処理する際、ルートの一致結果と検証結果をそれぞれ別の配列で保持します。ところが、不正な形式のリクエストに遭遇した場合、コードは検証用配列にエラーを追加する一方で、「continue」文によって対応するルートのエントリをスキップしてしまいます。

if ( is_wp_error( $single_request ) ) {
    $has_error = true;
    $validation[] = $single_request;
    continue;
}
$match = $this->match_request_to_handler( $single_request );
$matches[] = $match;

これにより、インデックスの不整合(desynchronization)状態が生じます。その結果、後続のリクエストがあるRESTエンドポイントのパラメータ規則に従って検証されながら、実際には別のエンドポイントのハンドラによって実行されてしまうことがあります。

この開示情報によると、攻撃者はこの挙動を悪用して、バッチ機能に対応したAPIルート全体でパラメータのサニタイズ制御を回避できるとされています。

このSQLインジェクションの発生源は、公開されている投稿一覧取得エンドポイントGET /wp/v2/postsにあるとされています。このAPIルートは、author_excludeパラメータによる著者の除外フィルタリングをサポートしており、これは内部的にauthor__not_inというクエリ変数として使用されます。

WordPressは入力が配列である場合には個々の値を安全に正規化しますが、スカラー値が渡された場合には、それが生のSQL文のNOT IN句にそのまま埋め込まれてしまう可能性があります。

if ( is_array( $query_vars['author__not_in'] ) ) {
    $query_vars['author__not_in'] = array_map(
        'absint',
        $query_vars['author__not_in']
    );
}
$author__not_in = implode(
    ',',
    (array) $query_vars['author__not_in']
);
$where .= " AND {$wpdb->posts}.post_author NOT IN ($author__not_in)";

通常の状況下では、RESTパラメータの検証機能により、攻撃者が任意のスカラー値を使ってこのコードパスに到達することは防がれています。しかし、今回報告されたBatch APIの不整合状態は、この保護を回避してしまいます。

Batch APIは通常GETサブリクエストを拒否しますが、今回開示された攻撃連鎖はバッチエンドポイントを再帰的に呼び出す方式を取っています。1層目でメソッド検証を回避し、2層目でauthor_excludeの検証を回避するという仕組みです。

結果として生じるSQLインジェクションは読み取り専用と説明されていますが、その後の悪用経路によってはるかに深刻な事態を招きます。この攻撃連鎖は、UNIONベースのクエリを使い、WordPressのリクエスト単位のオブジェクトキャッシュ内に偽造したWP_Postオブジェクトを作り出します。

これらのオブジェクトは、その後WordPressのoEmbedキャッシュ機能と相互作用し、制御されたoembed_cacheデータベースの行が攻撃者に制御されたメモリ上のメタデータと整合させられてしまいます。

この研究者によると、この手法はさらに発展させることができ、偽造したキャッシュエントリをcustomize_changesetの投稿に変換することが可能だといいます。WordPressはchangesetデータに含まれるuser_idを使ってchangesetを適用するため、ユーザーID 1に紐づけられた悪意のあるchangesetを用いれば、一時的にWordPress管理者権限を取得できてしまいます。

コンピュータサイエンス

最終段階では、WordPressの動的アクションフックが悪用されます。投稿ステータスと投稿タイプの値を偽造することで、この一時的な管理者権限が有効な状態のままparse_requestフックを呼び出すことができます。

これにより、元のBatch APIリクエストが権限昇格した状態で再実行され、攻撃者が制御するリクエストによって新たな管理者アカウントを作成できてしまいます。

攻撃者はその後、作成したアカウントでログインし、WordPressの管理画面から悪意のあるプラグインZIPファイルをアップロードすることができ、結果としてコード実行に至ります。

管理者は直ちにWordPressのセキュリティ更新プログラムを確認し、可能な範囲でRESTエンドポイントへの一般公開アクセスを制限するとともに、/wp-json/batch/v1への不審なリクエストがないかログを調査し、想定外の管理者アカウントやプラグインのインストールがないか確認する必要があります。

 脅威検出と迅速な調査を加速し、SOCを強化しましょう。 -> ANY.RUNをあなたのSOCに統合する 今すぐ。