GPT-5.6が約25ドルでWordPressのRCEを発見｜wp2shellの事実と現場の守り方

結論: セキュリティ企業 Searchlight Cyber の研究者が、OpenAIの推論モデル GPT-5.6（Sol）を使い、WordPressコアのプリ認証リモートコード実行（RCE）チェーンを約25ドル・実働10時間ほどで発見したと2026年7月20日に公表しました。この脆弱性は「wp2shell」と名付けられ、7月17日にすでに緊急パッチ（WordPress 7.0.2 / 6.9.5 / 6.8.6）が出ています。まず自社・顧客のWordPressを更新するのが先決で、そのうえで「AIが脆弱性発見のコストを一段下げた」という変化を冷静に受け止める、という2段構えが要ります。

この記事の要点:

• wp2shellは、WordPressのバッチAPI（/wp-json/batch/v1）のルート検証のズレと、コアのSQLインジェクションを連鎖させる未認証RCE。世界で推定5億サイトが動くWordPressのコア側の欠陥で、プラグインの有無に関係なく影響する（Searchlight Cyber・Aikido・CyberInsiderの報道による）
• 発見者はSearchlight CyberのAdam Kues氏。数学研究向けに公開されていたプロンプト手法をセキュリティ調査に転用し、GPT-5.6に約10時間走らせて発見。コストは月200ドルのサブスク換算で約25ドル。エクスプロイトブローカーが同種のRCEに約50万ドルを払う市場と対比されている（Searchlight Cyber・一次記事）
• WordPressは7月17日に緊急リリースを出し、強制自動更新を有効化。ただし自動更新を切っている環境・古いブランチは手動対応が必要。すでに実際の悪用の兆候も報じられている

対象読者: WordPressを運用・保守している開発者と情報システム担当、SESで顧客サイトやOSS資産に関わるエンジニア、AIがセキュリティに与える影響を追いたい方

読了後にできること: 自社・顧客のWordPressが危険な状態かを今すぐ判定して手を打てるようになり、「AIが脆弱性を見つけた」というニュースを、煽られずに事実と留保に分けて読めるようになります。

「AIが、ブローカーなら50万ドル出す脆弱性を、25ドルで見つけた」。こう聞くと、身構える人と話半分に聞く人に分かれると思います。どちらも早い、というのが正直なところです。実際に起きたのは、有名なWordPressのコアRCE「wp2shell」の発見に、OpenAIのGPT-5.6が使われていた、という公表でした。

僕自身、会社の日々の業務の多くをClaude CodeやCodexのようなAIエージェントに任せていて、コードを読ませて調べさせる作業がここ半年で実用の域に入ったのは肌で感じています。ただ、それが「攻撃側のコスト」まで動かし始めたとなると、話は現場の守りに直結します。ちなみに、このブログを載せているデュスクのコーポレートサイトはWordPressではありませんが、SESで関わる先ではWordPress資産はごく普通に存在します。なので、うちには関係ないと切り捨てられないニュースだと感じました。

この記事では、まず何が起きたのかを時系列で整理し、wp2shellの中身をかみ砕いたうえで、「どこまでが確認済みで、どこからが解釈なのか」を分けて解説します。そのうえで、エンジニア・SES現場が今すぐ取るべき対応と、この流れの受け止め方を整理します。

何が起きたのか — 2つのニュースが1本につながっている

このニュースは「WordPressの緊急パッチ」と「AIで脆弱性を発見」という別々に見える2つが、同じ人物・同じ脆弱性を軸につながっている点がポイントです。まず時系列で押さえます。

ポイントは、脆弱性そのもの（wp2shell）は責任ある開示を経てすでに修正済みで、7月20日に追加で明かされたのが「発見にAIを使った」という手法の話だ、という順序です。つまり緊急度の高いパッチ対応と、AIの能力に関する議論は、切り分けて読む必要があります。前者は今すぐの実務、後者は中期の構えの話です。

そもそも何の脆弱性か — wp2shellをかみ砕く

wp2shellは、単体の穴ではなく2つの弱点を鎖のようにつなぐタイプの攻撃です。報道によると、内訳はおおむね次の2つです。

• バッチAPIのルート取り違え: WordPressには複数のAPIリクエストをまとめて送れる /wp-json/batch/v1 という窓口があります。ここで「このリクエストを受け付けてよいか」を検証する段階と、実際に実行へ振り分ける段階の判断がズレていて、本来通すべきでない要求が通ってしまう
• コアのSQLインジェクション: 投稿系エンドポイントのあるパラメータ（author__not_in）経由で、データベースへの不正な問い合わせを差し込める

この2つが組み合わさると、ログインしていない匿名の攻撃者が、標準インストールのWordPressに対してコードを実行できる状態になります。怖いのは、これがプラグインのバグではなくWordPress本体（コア）側の問題だという点です。プラグインを入れていないから安全、という理屈が通りません。WordPressは世界で推定5億サイトが動くとされ、コアの欠陥は影響範囲がそのまま桁違いになります。

たとえるなら、マンションの共用エントランスのオートロックに、住人確認の手順と扉を開ける手順の間にすき間があって、確認をすり抜けて入られてしまう、という話です。各戸（プラグイン）の鍵の話ではなく、建物そのものの入口の設計に穴があった、というイメージが近いです。

影響を受けるのは6.9〜7.0.1系（RCEチェーンとして）で、修正版は7.0.2 / 6.9.5、SQLインジェクションのみ影響する旧ブランチ向けに6.8.6が出ています。

どこまで確認されているのか — 事実と留保を分ける

ここがこの記事でいちばん慎重に書きたい部分です。「AIが単独で脆弱性を見つけた」という要約は、正確ではありません。一次記事にあたると、確認できることと、そうでないことがはっきり分かれます。

確認できること（一次情報・複数の裏取りあり）:

• wp2shellが実在し、修正済みであること。WordPressの緊急リリースとして公開され、複数のセキュリティ企業が独立に報じています
• 発見・報告者がSearchlight CyberのAdam Kues氏であること。同社は責任ある開示を行い、猶予期間を設けたと説明しています
• GPT-5.6を使った点。Kues氏自身が経緯を公表しています
• 第三者による再現。Kues氏は「公開を週末まで見送っている間に、Calif氏とHacktronがGitHub上にPoCが出回る前に独立してチェーン全体を再現できた」と書いています。ここは「本人の主張」で終わらず、別の手で再現されている点が重要です
• 動作の実地確認。Kues氏は「半信半疑のまま、リモートサーバーに素のWordPressを立てて管理者のメールアドレスを盗ませたら、数分で私が設定したメールを表示した」と、エンドツーエンドで動くことを確認したと記しています

留保が必要なこと（解釈・言い方に注意）:

• 「AIがひとりで見つけた」わけではないこと。Kues氏は、調査対象の選定、プロンプトによる方向づけ、脱線したときの軌道修正といった人間の舵取りがあったと明言しています。「元のバグを渡して『RCEまで作れ』と頼んでも、人間の研究者がこの時間内にやり切れるかは分からない」とも書いており、モデルの速度と人間の判断が組み合わさった結果です
• 「25ドル」という数字の読み方。これは月200ドルのサブスクの週次利用枠の半分、という按分での概算です。純粋なAPI従量課金の実費とは前提が違うので、「誰でも常に25ドルで同じことができる」と一般化はできません
• CVE番号（各社報道ではCVE-2026-63030：バッチAPIのルート取り違え、CVE-2026-60137：コアのSQLインジェクション）は、セキュリティ各社の報道による採番として扱っています

AIによる脆弱性発見は、少し前まで「誤検知（フォールスポジティブ）だらけで信用できない」というのが定説でした。実際、あるMCPサーバー33個の検査では、手動レビューの結果約78%が誤検知だったという報告もあります（AI×セキュリティの現状として複数媒体が指摘）。今回のwp2shellは、その定説に対して「本物を、しかも人間が検証・再現できる形で出した」事例として見ると位置づけが分かりやすいです。

楽観論と慎重論 — AIによる脆弱性発見をどう受け止めるか

この話題は受け止め方が分かれます。両方を押さえておくのが、過剰反応も過小評価も避けるコツです。

楽観的な見方は、「攻撃側のコストが大きく下がった事実は無視できない」というものです。ブローカーが50万ドル出す水準の穴を、25ドル規模の計算資源で見つけ、第三者が再現できた。これは「AIがコードを読んで実在の脆弱性を鎖状につなぐ」能力が実用段階に入ったことを示す、という受け止めです。防御側にとっても、同じ道具で自社コードを先に洗える、という前向きな含意があります。

慎重な見方は、主に3点です。第一に、AIによる脆弱性報告は誤検知が多く、今回のように「本物で、再現された」ケースはまだ選ばれた事例だということ。第二に、成果の帰属です。人間の熟練した舵取りが前提なので、「AI単独の功績」と読むのは正確ではありません。第三に、同じGPT-5.6については、事前評価で「観測史上もっとも高いベンチマーク不正率」が報じられるなど、モデルの主張は都度検証すべきという文脈もあります。派手な見出しほど、一次情報で裏を取る規律が要ります。

デュスクとしての見立ては、どちらも部分的に正しい、というものです。AIがコード監査の実務に食い込んできたのは本物の変化です。一方で、それは「AIに任せれば安全」を意味しません。むしろ、AIの出力を検証し、責任を持って開示できる人間の価値が上がるという話だと捉えています。今回も、再現・検証・開示という地味な工程を回したのは人間でした。

エンジニア・SES現場への示唆

ここからが本題です。遠いニュースに見えて、現場に効く論点がいくつもあります。

まず、守りの即応力が問われます。wp2shellはコアの脆弱性で、パッチも強制自動更新も出ています。つまり「更新していれば防げる」種類の問題です。逆に言えば、自動更新を切っていたり、保守対象の棚卸しができていない現場が、そのまま穴として残ります。SESで複数の顧客環境に関わっていると、「誰がどのWordPressのバージョンを見ているか」の把握そのものが弱点になりがちです。

次に、攻撃と防御の両方でAIの前提が変わります。脆弱性発見のコストが下がるということは、攻撃者側も同じ道具を持つということです。今後は「公開されたばかりの脆弱性が、AI支援で急速に武器化される」スピードを前提に、パッチ適用の速さそのものが競争力になります。同時に、防御側もAIでコードを先回りして洗う運用を検討する価値が出てきます。

キャリアの観点でも意味があります。今回の事例で人間が担ったのは、何を調べるかの選定、プロンプトでの方向づけ、そして検証と開示という判断でした。手を動かす部分がAIに寄っていくほど、「AIに何をどう調べさせ、その結果をどう検証するか」を設計できるエンジニアの価値が上がります。これは、AIを日常的に使い倒している現場かどうかで差がつくところだと思います。

今すぐ確認・検討すべきこと

• 今日確認すること: 自社・顧客のWordPressのバージョンを確認し、6.9〜7.0.1系なら7.0.2 / 6.9.5へ更新する（6.8系は6.8.6）。判定用の公開チェッカー（wp2shell.com）でも状態を確認できます。自動更新が有効かも合わせて点検します
• 今週中にやること: 保守しているWordPress資産の棚卸し。どのサイトがどのバージョンで、誰が更新責任を持つのかを一覧化する。自動更新を切っている環境があれば、その理由と代替の更新フローを確認します
• 今月中に検討すること: 「公開直後の脆弱性がAI支援で速く武器化される」前提での、パッチ適用SLAとログ監視の見直し。あわせて、AIをコード監査など防御側で使う運用を小さく試すことも検討に値します

よくある質問

Q1. うちのWordPressは大丈夫ですか？

6.9〜7.0.1系を使っていてまだ更新していない場合は危険です。7.0.2 / 6.9.5（旧ブランチは6.8.6）へ更新してください。WordPressは強制自動更新を有効化していますが、自動更新を切っている環境は手動対応が必要です。

Q2. パッチはもう出ているのですか？

はい。2026年7月17日にWordPress 7.0.2 / 6.9.5 / 6.8.6が公開されています。この記事の前半は「発見にAIが使われた」という手法の話で、脆弱性自体は修正済みです。

Q3. 本当にAIが単独で見つけたのですか？

いいえ。発見者は、調査対象の選定・プロンプトでの方向づけ・軌道修正といった人間の舵取りがあったと明言しています。AIの速度と人間の判断が組み合わさった結果です。

Q4. 「25ドル」は誰でも同じ金額でできるという意味ですか？

いいえ。月200ドルのサブスクの週次利用枠の半分、という按分での概算です。前提が変われば金額も変わるので、一般化はできません。

Q5. これはWordPressだけの問題ですか？

脆弱性自体はWordPress固有ですが、「AI支援で実在の脆弱性を安く見つけられる」流れは、他のOSSや自社コードにも関わる話です。攻撃側・防御側の双方が同じ道具を持つ前提で構える必要があります。

まとめ

確定しているのは、WordPressコアの未認証RCE「wp2shell」が実在し、2026年7月17日に修正済みで、強制自動更新も出ている、という事実です。まずやるべきは、自社・顧客のWordPressを更新することに尽きます。そのうえで7月20日に明かされたのが、この発見にGPT-5.6が使われ、第三者による再現もされていた、という手法の話でした。

一方で「AIが単独で50万ドル級の脆弱性を25ドルで見つけた」という要約は、人間の舵取りとコストの前提を省いた言い方です。派手な数字ほど、事実と留保を分けて読む。攻撃側のコストが下がったのなら、防御側も同じ速さと道具で応じる。今回のニュースは、そのための良いリマインダーだと思います。

参考・出典

• Exploit brokers pay $500k for WordPress RCEs. I found one with GPT-5.6 and $25（https://slcyber.io/research-center/exploit-brokers-pay-500000-for-a-wordpress-rce-i-found-one-with-gpt5-6/）— Searchlight Cyber（参照日: 2026-07-21）【一次】。約25ドル・実働約10時間・第三者による再現・エンドツーエンド検証・人間の舵取りに関する記述の出典
• Unauthenticated RCE in WordPress core (wp2shell)（https://www.aikido.dev/blog/unauthenticated-rce-in-wordpress-wp2shell）— Aikido Security（参照日: 2026-07-21）。影響バージョン・修正バージョン・/wp-json/batch/v1・強制自動更新・発見者の出典
• WordPress releases emergency update for critical 'wp2shell' RCE flaw（https://cyberinsider.com/wordpress-releases-emergency-update-for-critical-wp2shell-rce-flaw/）— CyberInsider（参照日: 2026-07-21）。7月17日パッチ・推定5億サイト・チェッカー公開・悪用の兆候の出典
• CVE番号（CVE-2026-63030：バッチAPIのルート取り違え／CVE-2026-60137：コアのSQLインジェクション）はWordfence等セキュリティ各社の報道による採番（参照日: 2026-07-21）