Searchlight Cyber wp2shell WordPress RCE 於 GPT‑5.6 Sol Ultra 發現

TL;DR – 事件概述與重要性

Searchlight Cyber 利用 GPT‑5.6 Sol Ultra 模型(計算成本約 25 美元)發現 WordPress 批次 REST API 中的預驗證 SQL 注入,並串接多個邏輯漏洞以實現遠端程式碼執行(RCE)。完整的利用鏈證明了現代大型語言模型能自主發掘並武器化廣泛部署軟體的零日漏洞,這種能力在漏洞販售市場上價值高達 50 萬美元。


LLM 驅動的發現工作流程

結論: 精心設計的多代理提示可以讓大型語言模型在不依賴外部參考的情況下閱讀、分析並模糊測試整個程式碼庫,產出可行的零日漏洞。

研究人員將最新的穩定版 WordPress 原始碼克隆至 wordpress‑ctf/main/,移除 .git 目錄,並提供一個空的 third_party/ 資料夾。提示(見下方)指示模型:

  • 將任務視為純粹的程式碼分析問題——不使用變更日誌、也不進行網路比對。
  • 最多啟動四個代理,探索多樣的攻擊面(輸入解析、序列化、競爭條件等)。
  • 持續至少六小時才放棄。
Current task statement:
…
Your task is to identify the chain that allows for RCE …
Use multiagents aggressively …
Do not use changelogs, git history, or the internet …
Spend at least 6 hours on this before giving up.

模型在四小時後回報了預驗證 SQL 注入,研究人員透過部署全新 WordPress 實例驗證,確認模型能讀取管理員電子郵件。


根本漏洞:批次 API 驗證‑執行不同步

結論: class‑wp‑rest‑server.php 中驗證與執行迴圈不匹配,使攻擊者能在驗證一個端點的同時執行另一個端點,繞過所有消毒機制。

WordPress 通常以四個步驟驗證請求(has_valid_params() → sanitize_params() → permission callback → endpoint callback)。批次 API 將驗證與執行分成兩個獨立迴圈:

  1. 驗證迴圈 – 驗證每個子請求,並將布林值或 WP_Error 存入 $validation
  2. 執行迴圈 – 使用 $matches(處理器映射)與 $validation 來執行請求。

如果子請求觸發 is_wp_error($single_request),程式碼會 continue 而不$matches 推入對應項目。這會導致索引錯位,使 $validation[i] 不再與 $matches[i] 對應。結果,系統可能使用請求 A 的驗證結果去執行請求 B


SQL 注入原始(「sink」)

結論: 利用上述不同步,攻擊者可向 GET /wp/v2/posts 提供標量 author__not_in 參數,該參數會直接插入 SQL,形成典型的字串注入。

author__not_in 處理程式會對陣列元素使用 absint() 進行消毒,但對標量字串不做處理:

if ( ! empty( $query_vars['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'] )
        );
        sort( $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) ";
}

當參數為標量字串如 "0) OR 1=1 -- " 時,會原樣串接,產生 ... NOT IN (0) OR 1=1 -- ),導致返回所有資料列。


克服 GET 限制的遞迴批次呼叫

結論: 透過巢狀批次請求,可繞過批次 API 對 GET 方法的禁用,讓注入得以執行。

外層批次請求注入一個格式錯誤的請求(POST http://:)以使驗證不同步。於負載內,攻擊者再嵌入另一個批次呼叫,其內部請求使用 GET。因為 method 欄位的驗證只在第一個迴圈執行,內部的 GET 永遠不會被檢查,注入得以執行。

最終負載(為了清晰起見已裁剪)如下:

POST /wp-json/batch/v1
Content-Type: application/json

{
  "requests": [
    {"method":"POST","path":"http://:"},
    {"method":"POST","path":"/wp/v2/posts","body":{
        "requests":[
          {"method":"GET","path":"http://:"},
          {"method":"DELETE","path":"/wp/v2/posts/1","body":{"author_exclude":"0) OR 1=1 -- "}},
          {"method":"GET","path":"/wp/v2/posts"}
        ]
    }},
    {"method":"POST","path":"/batch/v1"}
  ]
}

執行此請求會返回 wp_posts 中的所有資料列,證實了 SQLi 成功。


從 SQLi 到 RCE:串接小工具

結論: 攻擊者利用記憶體中的文章快取、embed 處理以及 WordPress 的 customize_changeset 機制取得暫時的管理員權限,然後透過 parse_request 鉤子重新進入請求生命週期,建立新管理員帳號並上傳後門外掛。

  1. 快取投毒 – SQLi 產生的 UNION 查詢偽造假文章,WordPress 在請求期間將這些 WP_Post 物件快取起來。
  2. embed 濫用 – 透過嵌入本地文章([embed]/?p=10[/embed])WordPress 會在資料庫建立 oembed_cache 記錄。攻擊者可控制此記錄的 post_type,在快取與資料庫同步後將其轉為普通 post
  3. customize_changeset – 偽造的 customize_changeset 文章儲存 JSON,執行時會呼叫 wp_set_current_user(1),暫時取得管理員身分。
  4. 循環偵測小工具 – WordPress 的循環偵測邏輯會在不觸及 post_content 的情況下將文章的 post_parent 設為 0。透過在偽造文章之間建立父子循環,攻擊者迫使 WordPress 在保留受控的 post_content 同時執行 customize_changeset
  5. 鉤子重放parse_request 動作會在類型為 request 的偽造文章上被觸發。此鉤子在假管理員身份下重新執行整個批次請求,從而第二次建立管理員使用者。
  6. 後門部署 – 取得合法的管理員帳號後,攻擊者上傳惡意外掛 ZIP,最終在伺服器上取得完整程式碼執行權限。

時間線與成本

結論: 整個利用鏈在模型運行約十小時內完成,計算成本約 25 美元(基於每月 200 美元的訂閱方案)。

  • 提示工程與模型啟動 – 約 2 小時
  • 模型產生的預驗證 SQLi – 約 4 小時(含驗證)
  • 人工分析、鏈接拼接與最終負載構造 – 約 4 小時

社群在 Hacker News 上的回應

結論: 這篇報告引發了關於 50 萬美元漏洞賞金現實性、LLM 協助開發利用的創新性以及需要更好自動防禦機制的討論。

  • 有評論者質疑 50 萬美元的數字,認為提示本身可能才是商品。
  • 其他人指出鏈路的技術深度,認為遞迴批次呼叫與快取投毒步驟若無 AI 協助難以發現。
  • 少數人關注安全防護的護欄,指出 GPT‑5.5 之後的模型常會阻擋攻擊性安全提示,但作者仍成功。
  • 多位評論讚揚此報告揭示 LLM 能加速漏洞發現,同時警告不要美化「AI 黑客」的敘事。

對安全研究的影響

結論: 大型語言模型正成為漏洞發現的強大自主助理,將瓶頸從低階漏洞尋找轉移到高階編排與提示工程。

  • 速度: 複雜的多漏洞鏈條,過去需要人類數週完成,現在可在數小時內組合。
  • 技能轉移: 研究者需聚焦於定義攻擊面、撰寫有效提示與驗證模型輸出。
  • 防禦回應: 傳統靜態分析工具可能無法捕捉 LLM 組合的跨元件小工具;執行時防禦、請求層級驗證與嚴格的 API 消毒變得更為關鍵。
  • 經濟影響: 若利用商人願意為此類鏈條支付六位數金額,AI 產生的零日市場將持續擴大,迫使供應商採用 AI 輔助的程式碼審查與模糊測試。

針對特定 WordPress 漏洞的緩解措施

結論: 修補批次 API 的驗證邏輯並加強參數處理即可消除本文描述的攻擊面。

  1. 同步驗證與執行索引 – 確保驗證迴圈中的每一次 continue 也會在 $matches 中加入佔位項目。
  2. 強制標量消毒 – 在插入 SQL 前對標量 author__not_in 值套用 absint()(或使用預備語句式的逃脫)。
  3. 禁止遞迴批次呼叫 – 拒絕包含巢狀 /wp-json/batch/v1 請求的批次負載。
  4. 限制 embed 處理 – 驗證嵌入的 URL 必須為外部,或本地 embed 必須指向已存在的文章 ID。
  5. 在寫入資料庫前即拒絕不當的父子循環 – 讓循環偵測機制在任何資料庫寫入前即拒絕不合法的層級結構。

WordPress 核心維護者已收到通知,預計在即將到來的 6.7 版中提供修補。


最後的想法

結論: wp2shell 利用展示了 LLM 能自主發現成熟軟體中的高影響力零日,且其產出的利用鏈足以獲得半百萬美元的賞金。

此研究標誌著一個轉折點:安全團隊必須將 AI 產生的程式碼分析視為新興攻擊向量,投入 AI 輔助的防禦工具,並重新思考可能無意間鼓勵 AI 製作利用的賞金結構。

Sources

相關

  • Dispatch
  • Dispatch
  • 專案
  • Dispatch
  • Dispatch