7月20日、Searchlight Cyberが「Exploit brokers pay $500,000 for a WordPress RCE. I found one with GPT5.6 Sol Ultra and $25 › Searchlight Cyber」と題した記事を公開した。エクスプロイトブローカー（脆弱性の買い取り・転売業者）の相場で50万ドルで取引されるWordPressのRCE（リモートコード実行）ゼロデイを、OpenAIの推論特化モデル「GPT-5.6 Sol Ultra」と約25ドルのAPI利用コストで発見したという内容だ。

公開モデルと月200ドルのサブスクリプションを使い、世界5億以上のWordPressインスタンスに影響するゼロデイが発見できる時代が来た——この事実は、セキュリティ研究者だけでなく、サービスを運営するすべての開発者に刺さる。なお本脆弱性はWordPressに対してResponsible Disclosure（責任ある開示）が完了しており、修正済みバージョンへのアップグレードが既に可能な状態で公開されている。未更新のインスタンスを運営している場合は、早急なアップデートを推奨する。

$25で50万ドル相当のゼロデイを発見

Searchlight Cyberの研究者が用いた手法はシンプルだ。OpenAIがグラフ理論の難問「Cycle Double Cover予想」を解かせた際に公開したプロンプトをベースに改変し、WordPress最新安定版のソースコードを渡してGPT-5.6 Sol Ultraに解析させた。GPT-5.6 Sol Ultraは、OpenAIが提供する推論（reasoning）特化型モデルの一つだ。

使用したエージェント数は最大4つ、実行時間は6時間以上。かかったコストはProプラン（月200ドル）の週次利用枠の約半分、金額にして25ドル相当だ。

AIには意図的にインターネットアクセスや.git履歴の参照を禁止している。「パッチ済みバージョンとのdiffを見ればすぐ分かる」という「カンニング」を防ぐためだ。また、「攻撃者が現実的に達成できない前提条件を捏造する」というLLMの悪癖を封じるため、プロンプトにはpre-authentication to RCE in a typical production deployment with MySQLと明示した。

数時間後、モデルはプリ認証SQLインジェクションを報告してきた。研究者は半信半疑でリモートサーバーに素のWordPressをインストールし、モデルに管理者メールアドレスを盗み出させた。モデルは数分でそれを返してきた。

バグの核心：バッチAPIのインデックス同期ズレ

発見された脆弱性の起点は、WordPress 5.6（2020年）で導入されたバッチAPI（/wp-json/batch/v1）にある。このエンドポイントは認証不要でアクセスできる。

通常のAPIエンドポイントは「パラメータ検証 → サニタイズ → 権限チェック → 実行」という順序で処理される。しかしバッチAPIは検証と実行を2つのループに分けており、その実装に致命的なバグがある。

foreach ( $requests as $single_request ) {
    if ( is_wp_error( $single_request ) ) {
        $has_error    = true;
        $validation[] = $single_request;
        continue;  // ← ここが問題
    }
    $match     = $this->match_request_to_handler( $single_request );
    $matches[] = $match;
    // ... 検証処理 ...
    $validation[] = true;
}

最初のリクエストが不正な場合、$validation配列には結果が追加されるが、continueにより$matches配列には何も追加されない。この結果、$matches[i]と$validation[i]のインデックスがズレる（英語圏のセキュリティコミュニティでは「desync」と呼ばれる現象だ）。

実行フェーズでは「リクエストNの検証結果」を使いながら「リクエストN+1のハンドラ」を実行する状態になる。つまり、あるエンドポイントの検証を通過したパラメータを、別のエンドポイントに流し込める。検証と実行が「1対1で対応していない」という、見つけにくいが一度気づけば明快なバグだ。

SQLインジェクションの注入先

シンク（脆弱な処理の着地点）はGET /wp/v2/postsのauthor__not_inパラメータだ。

if ( is_array( $query_vars['author__not_in'] ) ) {
    $query_vars['author__not_in'] = array_unique(
        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) ";

配列ならabsintで整数にサニタイズされるが、スカラー値（文字列）が来た場合はそのままSQLに展開される。通常この経路は公開パラメータの検証で塞がれているが、バッチAPIのデシンクを使えば検証を迂回して任意の文字列を流し込める。

さらにモデルが示した解法が秀逸だ。バッチAPIはGETリクエストを許可しない。しかしモデルは「リクエストメソッドの検証もパラメータ検証として実装されている」と見抜き、バッチAPIをバッチAPIで再帰的に呼ぶことで制限を突破した。

SQLiからRCEへ、そして影響範囲

プリ認証SQLiからRCEへの昇格は、モデルが約4時間かけて構築した。パスワードのクラックやオフライン計算を行うことなく、読み取り専用のSQLiから管理者権限への昇格を実現している。研究者本人も「モデルが書くのに4時間かかったが、私が理解するのははるかに長くかかった」と記している。

影響範囲は深刻だ。WordPressは世界で5億以上のインスタンスが稼働しているとされ、プリ認証・フルRCEという攻撃の容易さを踏まえると、アップグレードを怠るリスクは極めて高い。元記事によると、自身のWordPressインスタンスが脆弱かどうかはwp2shell.comで確認できるとされている。

今回の一件が示すのは、AIによるゼロデイ発見が「理論上可能」から「実際に起きた」フェーズに入ったという事実だ。使ったのは公開モデル、公開プロンプト、月200ドルのサブスクリプション。防御側にとって、パッチ適用の優先度とスピードがこれまで以上に重要になる局面に入った。

詳細はExploit brokers pay $500,000 for a WordPress RCE. I found one with GPT5.6 Sol Ultra and $25 › Searchlight Cyberを参照していただきたい。