GPT-5.6 Sol UltraでWordPressの脆弱性「wp2shell」を発見|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年07月22日更新日時: 2026年07月22日

セキュリティ企業Searchlight Cyberは2026年7月20日、7月17日に緊急パッチが公開されたWordPress本体の未認証リモートコード実行(RCE)脆弱性wp2shellについて、その発見の経緯を詳細に公開しました。当サイトでは同脆弱性そのものについてすでに報じていますが、今回明らかになったのは、この脆弱性が人間の研究者ではなく、OpenAIのGPT-5.6 Sol Ultraというモデルによって、複数のAIエージェントを並行動作させる手法で発見されたという事実です。研究者が用意したのは1本のプロンプトと約25ドルの利用料のみで、そこから10時間程度のうちに、WordPressの中でも屈指の堅牢さで知られる本体コードに対し、未認証のSQLインジェクションを起点として管理者権限を奪取し、最終的にコード実行に至る一連の攻撃連鎖が組み立てられました。

1 サマリー
2 整理表
3 発端-数学の未解決問題を解いたモデルへの興味
4 発見された脆弱性の技術的概要
5 RCEへの昇格に使われた独創的な手口
6 研究者自身の評価-「AIなしでは10時間で不可能」
7 情報システム部門への示唆
8 出典

サマリー

Searchlight CyberのAdam Kues氏は、OpenAIのGPT-5.6 Sol Ultraに対し、複数のAIエージェント(最大4体)を用いた脆弱性調査を指示するプロンプトを与え、WordPress本体のソースコードを解析させました
用いられたプロンプトは、OpenAIが数学の未解決問題であるCycle Double Cover予想を解かせた際に公開したプロンプトを、脆弱性調査向けに改変したものです
モデルは調査開始からおよそ4時間で、WordPressのBatch API(バッチAPI)における検証処理と実行処理のずれを突いた、未認証のSQLインジェクションを発見しました
その後さらに4時間ほどをかけ、モデルはこのSQLインジェクションを、管理者権限の奪取からリモートコード実行(RCE)にまで昇格させる攻撃連鎖を完成させました
総利用コストは、月額200ドルのサブスクリプションの週間利用枠の50%相当、日割り計算でおよそ25ドルにとどまりました
攻撃連鎖には、リクエストごとのメモリ内投稿キャッシュの汚染、oEmbed機能の悪用によるデータベース行の捏造、カスタマイズ変更セット(customize_changeset)へのなりすまし、投稿階層の循環参照検知ロジックの悪用、そしてparse_requestフックを利用したリクエストの再実行という、複数の独創的な手口が組み合わされていました
Kues氏は、この攻撃連鎖を人間の研究者だけで10時間以内に発見・完成させることは不可能だっただろうと評価しています

整理表

項目	内容
公表日	2026年7月20日
公表元	Searchlight Cyber(Adam Kues氏)
発見に使用されたAIモデル	OpenAI GPT-5.6 Sol Ultra
手法	最大4体のAIエージェントを並行動作させるマルチエージェント方式
SQLインジェクション発見までの所要時間	約4時間
RCEへの昇格完了までの追加所要時間	約4時間(合計10時間強)
利用コスト	月額200ドルサブスクリプションの週間枠50%相当(日割り約25ドル)
起点となった脆弱性	Batch APIの検証・実行の二重ループ処理におけるインデックスのずれ(CVE-2026-63030)
悪用されたSQLi	WP_Queryのauthor_excludeパラメータの型検証不備(CVE-2026-60137)
RCEへの主要な昇格手口	メモリ内投稿キャッシュ汚染、oEmbedキャッシュの捏造、customize_changesetへのなりすまし、投稿階層の循環参照検知の悪用、parse_requestフックによるリクエスト再実行
対象への影響	WordPress 6.9.0〜6.9.4、7.0.0〜7.0.1(既報のとおり7.0.2等で修正済み)

発端-数学の未解決問題を解いたモデルへの興味

Kues氏によると、今回の調査の発端は、GPT-5.6 Sol Ultraが数学の未解決問題であるCycle Double Cover予想を解いたという話題でした。OpenAIはこの際に使用したプロンプトを公開しており、Kues氏はセキュリティコミュニティでこのプロンプトが話題になっているのをほとんど見かけなかったものの、難解な数学の問題を解けるほどのプロンプトであれば、脆弱性調査にも応用できるはずだと考えました。

Kues氏はこのプロンプトを脆弱性調査向けに改変し、最大4体のAIエージェントを積極的に用いること、そして少なくとも6時間はあきらめずに調査を続けることを指示したうえで、WordPress本体のソースコードに向けて実行しました。プロンプトでは、変更履歴やインターネット上の情報を使って既知の修正パッチとの差分を取るような調査手法を明確に禁止し、コードそのものを一から分析すること、探索の切り口が偏らないよう複数の異なるアプローチを並行して維持すること、そして行き詰まったアプローチには新しい着想がない限り固執しないことなどが指示されていました。WordPress本体だけでなく、依存する周辺ライブラリのソースコードも監査対象に含めてよいとされていた点も特徴的です。

発見された脆弱性の技術的概要

Kues氏が調査結果を確認したところ、モデルは未認証のSQLインジェクションを発見したと報告していました。半信半疑で実際にWordPressの検証環境にこの手法を試したところ、わずか数分で管理者のメールアドレスを窃取できることが確認されました。この脆弱性の技術的な詳細(WordPress 6.9で導入されたBatch APIにおける検証・実行の二重ループのずれと、WP_Queryのauthor_excludeパラメータの型検証不備を組み合わせたもの)は、当サイトで既報の記事で解説したwp2shellそのものであり、CVE-2026-63030およびCVE-2026-60137として、2026年7月17日にWordPress 7.0.2等で修正されています。

もっとも、このSQLインジェクションは読み取り専用であり、WordPressのパスワード等の認証情報はハッシュ化されて保存されているため、データベースを読み取れるだけでは管理者アカウントの乗っ取りには直結しません。Kues氏がモデルに対し、このSQLインジェクションをRCEにまで昇格できないか尋ねたところ、およそ4時間後にモデルは、パスワードの解読やオフラインでの計算処理を一切必要とせずに管理者権限へ昇格できる手法を示しました。

RCEへの昇格に使われた独創的な手口

Kues氏が特に驚いたのは、このRCEへの昇格に用いられた一連の技術です。

WordPressはパフォーマンス向上のため、リクエスト処理中に取得した投稿データをメモリ上に一時的にキャッシュする仕組みを持っています。今回のSQLインジェクションを使えば、UNION構文によってデータベースから返される投稿データを偽装でき、このメモリ上のキャッシュに任意の内容を注入できます。ただし、この偽装された投稿はデータベースの実データに裏付けられていないため、単体では大きな影響を及ぼせません。

そこでモデルが目をつけたのが、WordPressのoEmbed機能です。記事中に埋め込みリンクを指定すると、WordPressはその内容をキャッシュするため、oembed_cacheという種類の投稿としてデータベースに実際の行を作成します。この埋め込み先として存在しない投稿IDを指定すると、実データを伴わないoembed_cache行がデータベース上に作成されます。ここに再びSQLインジェクションを使ってメモリ上の偽装データを注入すると、データベース上の実データとメモリ上のキャッシュとの間に食い違いが生じます。WordPressはこの食い違いを検知すると、メモリ上の内容を優先してデータベースの行を上書きしようとするため、攻撃者は事実上、任意の種類の投稿をデータベース上に捏造できることになります。

次にモデルが着目したのが、customize_changesetと呼ばれる特殊な投稿タイプです。これはサイトのテーマ設定変更を一時的に保存する仕組みで、変更内容にはその変更を誰の権限で適用するかを示すユーザーIDが含まれています。このユーザーIDに管理者のものを指定した変更セットを偽装し、WordPressに適用させることで、匿名の攻撃者であっても一時的に管理者としての権限を得ることができます。ただし、変更セットの中身を格納するpost_contentフィールドは、oEmbedによる上書き処理で別の内容に固定されてしまうため、そのままでは細工した変更セットの内容を注入できません。

この制約を回避するためにモデルが使ったのが、WordPressの投稿階層における循環参照検知ロジックです。ある投稿を自分自身の親に設定するなど、階層構造に循環が生じるとWordPressはこれを検知し、該当する投稿の親IDを強制的にリセットします。このリセット処理はpost_contentを上書きしないため、偽装した変更セットの内容(post_content)を温存したまま、この循環参照の解消処理経由でデータベースに書き込ませることができます。この技法を2段階に組み合わせることで、モデルは最終的にparse_requestという、リクエスト処理全体を最初からやり直させるフックを呼び出すところまでたどり着きました。このフックが呼ばれた時点では、すでに一時的に管理者権限が付与された状態が保持されているため、最初のリクエストに仕込んでおいた管理者アカウント作成のリクエストが、2周目の処理で正常に成功します。あとは、作成した不正な管理者アカウントでログインし、標準のプラグインインストーラーから悪意あるプラグインをZIP形式でアップロードするだけで、サーバー上でのコード実行が達成されます。

研究者自身の評価-「AIなしでは10時間で不可能」

Kues氏は、この一連の攻撃連鎖がわずか10時間程度で完成したことについて、2022年のChatGPT登場以来あらゆる主要モデルを使ってきた経験を踏まえても、GPT-5.6がそれ以前のモデルと比べて脆弱性調査の能力で大きな飛躍を遂げていると評価しています。特に、GETリクエストへの制限を回避するための再帰的なバッチ呼び出しの発想、管理者権限への一時的な昇格にキャッシュの食い違いを利用する着眼点、そしてparse_requestフックを呼び出すことでリクエストを昇格した権限のまま再実行させるという一連の手口は、これまで人間の研究者だけの領域だと考えていたと述べています。

同氏は、たとえ人間の研究者に最初のバグそのものを教え、そこからRCEへの昇格だけを依頼したとしても、10時間という時間内に完成させられたかどうかは分からないとしたうえで、複数の異なる手がかりを見出し、コードベース全体にわたってそれらを鎖のようにつなぎ合わせる能力こそが優れたセキュリティ研究者の条件の一つであり、今回のモデルはそれを人間離れした精度と明確さで成し遂げたと総括しています。同氏はまた、モデルの能力が向上するにつれて、セキュリティ研究という営みそのものが、どの製品・領域をどれだけの時間調査するかを判断し、プロンプトで調査の方向性を導くといった、より上位の意思決定的な作業へと変化していくのではないかとも述べています。

情報システム部門への示唆

今回の事例は、脆弱性調査におけるAIの実力が、単発の既知パターン検出から、複数の脆弱性を独創的に組み合わせる高度な攻撃連鎖の構築へと確実に進化していることを示しています。当サイトで既報のGoogleが確認したAI生成の可能性が高いゼロデイエクスプロイトや、OpenAIのCodex Securityが50万件超の脆弱性を自動修正した事例、そしてHugging Faceが公表した自律型AIエージェントによる侵害インシデントともあわせて考えると、AIによる脆弱性の発見・悪用能力は、防御側・攻撃側双方にとって、もはや無視できない現実的な要因になりつつあります。

今回はSearchlight Cyberという防御側の研究者がこの能力を先んじて活用し、WordPressへの責任ある開示とパッチ提供を経て被害の拡大を防ぐ結果となりましたが、同様の能力は悪意ある攻撃者によっても等しく利用可能です。既報のとおりwp2shellはすでに公開PoCと実際の悪用の兆候が確認されており、WordPressサイトを運用する組織は速やかなバージョン更新が必須です。あわせて、自社で利用しているソフトウェアのアップデート・パッチ適用サイクルそのものを、AIによる脆弱性発見のスピードに見合った速さへと見直していくことが、今後さらに重要になっていくと考えられます。