人工智慧
企業愛用的 AI 工具，竟是駭客新目標？Pwn2Own 2026 示警軟體供應鏈風險升溫
趨勢科技 FTR 團隊現場觀察：從 Vibe Coding 擴散到 AI 代理程式的架構性漏洞，GenAI 同時是攻擊武器、也是攻擊目標。 今年在柏林舉行的 Pwn2Own 駭客競賽讓世人看到 AI 堆疊正暴露於怎樣的風險，同時也看到這些工具所承諾、與它們所能承受的之間有多大差距，而這一切都指向其底層資安基礎的脆弱。
Save to Folio
重點摘要
- AI 現在既是獵人、也是獵物。在 2026 年 Pwn2Own Berlin 駭客競賽上，參賽者使用 LLM 和代理式程式設計工具來尋找漏洞，諷刺的是，包括 Claude Code、Codex 和 Cursor 在內的 AI 工具也都名列在攻擊目標名單上。
- Claude Code、OpenAI Codex 和 Cursor 可被攻擊的弱點全都能追溯至幾個共同的原因：底層的開發人員工具過於強大，以及使用者過於信任 AI 代理。
- 參賽的每支隊伍都在工作流程的某個環節使用了 LLM，不過所有隊伍也都表示其探索的階段誤判率很高，這一點與傳統的資安研究一樣。然而，速度上的優勢才是重點，而非準確性。
- 像 Ollama 和 ChromaDB 這樣的工具經常暴露在網際網路上，所以駭客若能成功攻破這些工具，或是 Nvidia Container Toolkit，那就有可能存取其底層的主機，而非只有模型。
- 明年，氛圍程式設計 (vibe coding) 與供應鏈風險正在醞釀一場更大、更混亂的競賽。毫不相干的專案存在著相似的程式碼、開發人員工具可能遭到濫用，還有持續不斷的供應鏈攻擊，這些全都意味著攻擊面只會隨著軟體開發與漏洞發掘速度的加快而成長。
Pwn2Own Berlin 競賽已於 5 月 14 日至 16 日在柏林舉行的 OffensiveCon 大會上完美落幕，這是它連續第二年在柏林舉辦。Pwn2Own 是由全球最大非限定廠商漏洞懸賞計畫 TrendAI™ ZDI 所舉辦，廣邀資安研究人員同場較勁來發掘熱門軟體和硬體中的漏洞。去年的競賽首次出現新的 AI 競賽項目，並發現了 CVE-2025-49844 (ZDI-25-933) 這個 Redis 的「釋放後再利用」(use-after-free) 重大漏洞，以及 CVE-2025-23266 (ZDI-25-626) 這個 Nvidia Container Toolkit 的特權提升漏洞。
在所有 AI 項目當中，總共有 13 個可攻擊的目標。在 AI 資料庫 (通常為向量儲存庫) 項目中，只有 Chroma 和 Oracle Autonomous AI Database 成為參賽者的攻擊目標。在程式設計代理項目中，參賽者嘗試攻擊了所有的目標：Anthropic Claude Code、Cursor 和 OpenAI Codex。在本機推論項目中，只有 LiteLLM、LM Studio 和 Ollama 成為攻擊目標。最後在 Nvidia 項目，只有 Megatron Bridge 和 Container Toolkit 成為駭客試圖攻擊的目標。全部加起來，實際上只有這 10 個目標成為研究人員的攻擊對象。
本次競賽所有項目的報名人數都刷新紀錄，因此我們必須對參賽者進行篩選。不過到了在比賽結束時，棄賽的人數也超出我們預期。這實在有點可惜，至於原因，我們不想多加揣測。不過，最後所有參賽者獲得的獎金加起來將近 130 萬美元，依然相當可觀。
我們將最大的獎保留給高衝擊性的作業系統、虛擬化監管程式 (hypervisor) 以及瀏覽器漏洞。然而，由於意識到 AI 攻擊目標的重要性與日俱增，因此，某些 AI 攻擊目標贏得的獎金也不小。其中，獎金最高的項目是 NVIDIA 和推論攻擊目標。
當提到 AI 系統時，我們通常第一個想到的是推論：從輸入來導出預測。傳統上，我們想到的是像 Ollama、LM Studio 或 Nvidia Container Toolkit 這類可代管模型供人存取的系統，或是像 LiteLLM 這樣的抽象層與代理器層。
Ollama 可讓使用者自行代管 (self-host) 許多模型，只要主機擁有足夠的 GPU 和記憶體。例如 Google 的 Gemma 4 或 OpenAI 的 GPT-OSS 這類大型語言模型 (LLM) 以及 Nomic 的向量嵌入 (embeddings)，都能以這種方式在本機執行。由於 Ollama 也經常暴露在網際網路上，因而成為駭客覬覦的目標。
在 Pwn2Own 這樣的競賽中，像 Ollama 這種經常更新的系統並非最佳的攻擊目標。參賽者可能花了好幾個星期的時間來研究某個漏洞攻擊手法，結果卻發現在最新的版本上無法使用。不過，Out Of Bounds 團隊卻很厲害地找到了兩個漏洞，其中一個是已知但尚未修補的漏洞。許多暴露在網際網路上的 Ollama 執行個體都可能已遭篡改或用於推論，但這個漏洞卻可讓駭客存取底層的主機。
Nvidia 的 Container Toolkit 是另一種情況，這是一套可讓 Docker、Kubernetes 或類似容器存取 Nvidia GPU 的函式庫。它讓使用者能執行一些高效能的工作，尤其是從容器環境內部執行 LLM 推論。所以當駭客攻擊得逞時，有可能讓駭客存取容器本身，或者 (更糟的情況是) 存取主機系統。有三組人馬嘗試了這項攻擊，其中有兩組成功，分別是 Chompie (IBM X-Force 的 Valentina Palmiotti) 和 PWN2DACA 團隊。實務上，駭客必須已經擁有容器環境的某些存取權限才能發動這類攻擊，但要將漏洞攻擊手法串連起來並不容易。
LM Studio 跟 Ollama 很像，都是用來代管 AI 模型和向量嵌入，但它的使用者介面較為直覺，而且還提供其他 AI 相關的功能，例如：檢索增強生成 (RAG)，這是一種為使用者提示提供相關情境以減少幻覺的常用方法。但與 Ollama 不同的是，它通常優先部署在本機，因此不太常暴露在網際網路上。這是一個以 Electron 為基礎所開發的圖形使用者介面 (GUI) 應用程式，因此許多 Electron 原本就存在的問題它都有。所以，OtterSec 和 Starlabs 會發現各種漏洞也就不令人意外，不過可惜 Qrious Secure 在中途棄賽。
代理式 AI 程式設計系統同樣也成了本次競賽的攻擊目標之一，OpenAI 的 Codex 早在 ChatGPT 對外公開之前就已經成為各種程式碼編輯軟體的一項擴充功能 (plugin)。如今，它仍可當成擴充功能來使用，但也有獨立的雲端應用程式版本。有五支隊伍在競賽中嘗試攻擊 Codex，雖然他們發現的漏洞都很像，而且基本的概念也是眾所周知，但大多還是被認定為非重複漏洞。不過還是有一組失敗，另有一組跟已經發現的漏洞衝突。
Anthropic 的 Claude Code 是最近才加入這個項目，但馬上就受到歡迎，而且非常熱門，有四支隊伍以它為目標。這些隊伍發現的漏洞都很類似，而且有兩個案例被認為與本次競賽先前發現的漏洞衝突，看來抽籤運氣真的很重要。
Cursor 只遭遇到 Viettel 和 STARLabs 兩組人馬的攻擊，最終都完全成功。
以上三種 AI 程式設計工具的問題似乎都來自相似的源頭，也就是跟 AI 代理所使用的底層基本架構有關。這些常見的開發人員工具所演化出的某些功能，在 GenAI 時代反而變成了累贅。此外也造成了一些信任上的誤判，當 AI 代理要求使用者接受某些風險時，使用者也許無法正確評估這些風險。
LLM 本身確實有些用處，但卻容易出現幻覺。為了解決這個問題，許多 GenAI 驅動的應用都會從可信賴的資料來源取得一些資訊來彌補提示的不足，這時候我們通常使用向量儲存 (vector store) 來加以補強，也就是一般所稱的「檢索增強生成」(Retrieval-Augmented Generation，簡稱 RAG)。這樣就可以藉由其向量嵌入 (embeddings) 來取得類似的文字，進而找出最接近我們想要的文字。
ChromaDB 是一個開放原始碼的向量搜尋導向資料庫，專為 AI 應用而打造，但它卻有許多執行個體暴露在網際網路上。一般來說，它的安全性都經過強化，但 Out Of Bounds 團隊卻還是找到了一個遠端漏洞攻擊手法。雖然許多暴露在外的 Chroma 執行個體本來就不需憑證就能存取，但這個漏洞攻擊手法卻不只可能讓駭客存取原本應該受保護的執行個體，還能存取主機系統。這一點之所以特別麻煩，是因為這些資料庫中的資料可能很敏感。
在 Oracle Autonomous AI Database 項目中只有一支隊伍嘗試攻擊，但沒有成功。
Nvidia 的 Megatron Bridge 是一種可讓模型在 Hugging Face 格式與 Nvidia Nemotron 格式之間互相轉換的方式。有四支隊伍嘗試攻擊這個目標，不過最後一支隊伍所發現的與先前發現的漏洞衝突。只要軟體需要輸入資料來運作，駭客就能藉由篡改資料來進行攻擊。該團隊表示他們已經發現了多種漏洞攻擊手法，儘管最終只需一種手法就能贏得獎金。
我在親身參與的揭露案例中，曾經詢問參賽者有關他們使用 GenAI 的情況，他們所有人都表示會在過程中以某種形式使用 LLM。幾乎每個人都會用它來製作每個漏洞攻擊手法都必須附上的強制性白皮書。尤其是非英文系的隊伍，他們發現 LLM 在翻譯上很好用 (儘管某些遣詞用字怪怪的)。許多人會使用某種程式設計代理來進行漏洞的初步發掘工作，儘管每個人都說這階段的誤判率很高。
這一點不令人意外，而且跟一般「正常」的漏洞發掘程序一樣，很多時候會掉入死胡同。另有某些隊伍表示他們主要是將 GenAI 用來開發漏洞攻擊手法，尤其是在攻擊中利用加密編碼來躲避端點偵測及回應 (EDR) 系統的偵測。在我親自到場的揭露案例中，沒有人表示有在使用 Anthropic Mythos 或參與了 AI 資安計畫。儘管 Mythos 目前已對外發表 (也就是 Fable 5)，但因為某些限制的關係，對資安研究人員來說並非特別有用。
根據我個人使用這些代理式 AI 工具的經驗，我發現它們有助於閱讀大量的程式碼，因為如果用人工方式的話，會花費我更多時間。而且，雖然我看得懂 Python 或 C++，但我不了解 Rust 或 Go 的所有細節，不過這對代理式 AI 程式設計工具來說卻一點也不費力。然而令人驚訝的是，這些工具底層的機制卻比人們所想像的還要原始，不僅大量使用了「grep」和「find」，還會執行簡單的 Python 程式碼，並從網際網路下載相關內容等等。完全沒用到 SMT 求解器 (SMT solver) 這類精密工具或程式相依性圖形。
我想差別在於，代理式 AI 程式設計工具分析的速度比我快得多，而這已經足以媲美一名熟練的分析師。當我在測試程式設計代理的極限時，我發現我可以在 AI 代理發現我們的對話可能違反政策之前，套出非常接近漏洞攻擊手法的內容。而這一切都沒用到那個神祕的 Anthropic Mythos，不過我倒是花掉了很多 token。最後，我覺得驅動 GenAI 模型的工具可能比 GenAI 模型本身更重要。
明年，我預料 Pwn2Own 參賽者將會使用自己開發的漏洞發掘工具，甚至使用本機模型來避免資訊外洩。ㄊ 而且，還有一個問題是氛圍程式設計所生成的程式碼似乎都很像，所以，即使是不相干的專案也可能存在著類似的問題。此外，我們還要面對軟體供應鏈攻擊，以及某些程式設計工具的功能可能被濫用。明年，隨著軟體開發的腳步和漏洞發現的速度同步加快，參賽和棄賽的人數也許會雙雙再創新高。