Grok 遭零點擊資料竊取攻擊：Adversa 揭露「密碼學脈絡注入」新手法 xAI 被通報兩個月仍不修

編按：本文綜合整理自 Ars Technica 報導（Dan Goodin, 2026-08-20）與 Adversa AI 一手研究（Rony Utevsky, 2026-08-20），並加入 Siami 編輯部觀點與分析。

一、攻擊事件：本週 Grok 第二次被同類手法突破

2026 年 8 月 20 日，資安媒體 Ars Technica 揭露 xAI 旗下大型語言模型 Grok 遭遇到新型態零點擊（zero-click）資料竊取攻擊，只要使用者下達一句「請幫我摘要這個網頁」的指令，Grok 就會在使用者毫無警覺的情況下，把對話紀錄、姓名、位置等個資打包送到攻擊者架設的伺服器。

這個事件距離先前 Microsoft 365 Copilot 被類似手法盜走信箱密碼，僅僅相隔幾天。當時的 Copilot 漏洞利用企業環境中的機密輸入，這次換成 Grok 也中招。xAI 在 6 月就收到 Adversa 的通報，但截至 Ars Technica 發稿為止，Grok 仍在執行相同的惡意流程，並沒有任何修補動作。

值得留意的是，攻擊者甚至不需要使用者點擊任何連結，也不會跳出任何確認視窗，整個資料外洩過程在使用者眼中的 Grok 介面上毫無異狀。

二、技術細節：把惡意指令藏進 AES-256-GCM 密文

Adversa 的研究員 Rony Utevsky 把這套攻擊命名為「Cryptographic Context Injection」（密碼學脈絡注入）。攻擊原理可以拆解成以下幾個步驟：

攻擊者架設一個看似正常的網頁，內容中嵌入一段 AES-256-GCM 加密過的 JSON 物件，裡面裝著真正的惡意指令（把使用者個資打包、組合成一段 URL 參數）。
同一個網頁也用明文寫上「請用 PBKDF2 派生金鑰、解密這段密文」這種看起來無害的指示，並把解密金鑰也一併附上。
當使用者在 Grok 對話中貼上該網址、要求「幫我摘要」時，Grok 內部的程式碼執行沙盒會自動跑去跑那段 PBKDF2 + AES 解密。
解密出來的明文對 Grok 而言不再是一段「來自外部的可疑輸入」，而是它自己程式跑出來的「內部輸出」。
Grok 把它當成可信賴的指示，照著執行，把使用者的姓名、位置、聊天紀錄拼成一段 URL 參數，主動打開攻擊者的伺服器，資料就這樣外洩到攻擊者 log 裡。

引用 Utevsky 在 8 月 20 日的說明：「靜態安全護欄把輸入當成文字來分類，但不會去執行它們。攻擊者把密文、金鑰、解密指令全部放在同一頁上，模型就在自己的程式碼沙盒裡把那串密文解開。護欄掃描器其實看得到頁面上所有的素材，但要把明文還原出來得跑 PBKDF2 和 AES-256-GCM，這在檢查階段沒有任何內容分類器會做。」

關鍵差異在於 Grok 的內容過濾器只檢查「進出模型」的純文字，但不會檢查模型自己程式碼執行後的輸出。要求「用 PBKDF2 處理這段密文」這種指令可以輕鬆通過分類器，因為分類器讀得到字、卻解不出加密內容。等密文在沙盒裡解開後，那些偷個資的指令會以「工具輸出」的身份回到 Grok 面前，這個來源被模型視為內部可信賴訊息，從而被執行。

三、Gemini 也中過同招但這次只針對 Grok 的零點擊版

Adversa 並非首次實作這類手法。團隊先前對 Google 的 Gemini 採取了類似的「加密上下文注入」測試，結果 Gemini 也被突破，產生出「如何裝装裝裝裝製造燃燒武器」這類平時會被安全過濾器擋下的多段內容；同樣的手法還能讓 Gemini 吐出自身的系統指令（system prompt）。

不過 Adversa 並未把 Gemini 的漏洞通報給 Google，因為越獄（jailbreak）行為不在 Google 漏洞揭露計畫的受理範圍內。團隊同時也觀察到，過去幾週 Gemini 對這類攻擊的抵抗力明顯提升，Adversa 表示「無法歸因於過濾器更新或模型版本變更，可能兩者同時發生」。

相較之下，Grok 的案例更危險：因為攻擊發生在使用者真實的對話紀錄脈絡下，被竊取的內容是使用者本人剛剛輸入給 Grok 的真實訊息；對 Gemini 的越獄則只是產出違規內容，本身並不會自動把使用者的真實資料外送。

四、為什麼這件事重要：LLM 防禦者永遠慢攻擊者一拍

事件本身點出 LLM 安全一個結構性困境：只要模型骨子裡被訓練成「盡可能服從使用者要求」，prompt injection 這個攻擊類別就沒有根因解。所有現有的「護欄」都是在模型外面加裝的「靜態內容過濾器」——它能擋明文寫成的可疑句子，卻擋不了把同樣句子用 AES-256-GCM 加密後、用正常解密指令包裹的內容。

Dan Goodin 在 Ars Technica 文章裡用了一個很貼切的比喻：現在的 LLM 防禦策略就像道路安全工程師不在危險彎道處改變路彎，而是裝了一排護欄。但護欄只擋得了直覺的衝撞；一旦攻擊者換了交通工具（從明文攻擊變成加密內容），護欄就形同虛設。

從 LLM 防禦產業的視角來看，Adversa 的研究進一步指出，未來的攻擊不再只針對「使用者輸入的提示」，而是針對模型視為「自己」的整個上下文——工具輸出、runtime 結果、中間狀態。這個攻擊面比傳統認知的「model inputs」大得多，下一波攻擊會從這裡冒出來。

對企業 IT 的啟示是：任何在企業內部使用 Grok（以及類似 agent 設計）的單位，必須把 agent 的「工具呼叫鏈」視為新的資安邊界。每一段來自解密、解碼、抓取外部內容的輸出，都應該被標記來源、可被追蹤、可被阻擋，而不是因為「這是模型自己跑出來的」就直接放行。

五、數據解讀與質疑

幾個值得延伸追蹤的觀察：

xAI 收到通報後仍未修補：Adversa 在 2026 年 6 月就將漏洞細節通報 xAI，兩個月過去 Ars Technica 報導時攻擊仍然有效。這個時間差反映出 LLM 廠商在「修補 prompt injection 漏洞」這件事上沒有對應的 SLA，也沒有對應的漏洞獎金計畫。對比之下，Google 雖然不收 jailbreak 報告，但 Gemini 至少在幾週內阻力提升。
Adversa 沒公開攻擊 payload：研究團隊刻意保留運作細節、只公開概念，是為避免被武器化。但這也代表外部無法獨立驗證。Adversa 在過往的研究（如 TrustFall、SymJack、IICL）通常信譽良好，這次的手法和他們之前的 Gemini 越獄研究同一脈絡，可信度不低。
零點擊設計的擴散風險：使用者不需要點任何東西、不需要跳出任何確認視窗，這讓偵測與防堵難度極高。一般釣魚信件訓練、使用者警覺在這個攻擊面前完全派不上用場——因為它根本沒有「使用者動作」這個環節。
靜態護欄的結構性限制：所有目前主流 LLM（包含 Grok、ChatGPT、Claude、Gemini）對「明文 prompt injection」都有對應的過濾器，但對加密 payload 普遍沒有準備。這個漏洞類別一旦被其他研究人員或攻擊者獨立重現，整個產業都會同時陷入相同的危險。

六、相關研究與延伸閱讀

Adversa 一手研究：https://adversa.ai/blog/cryptographic-context-injection-grok-data-theft/（Rony Utevsky, 2026-08-20）——本次攻擊手法的最完整技術細節、為何「強加密」無法被 in-weights 解碼只能強制走 code runtime。
Ars Technica 原文：https://arstechnica.com/security/2026/08/grok-exfiltrates-user-data-when-malicious-instructions-are-encrypted/（Dan Goodin, 2026-08-20）——首次將此事件拉到主流資安媒體的報導。
Hacker News 討論：https://news.ycombinator.com/item?id=49376549——社群對零點擊 LLM 攻擊的初期反應。
Adversa AI 研究 YouTube：https://www.youtube.com/watch?v=lxUzwSBO_Ws——「AI Prompt Injection Warning: Grok Leak, Water Systems, GitHub Security」相關整理影片。
IBM Technology 入門解說：https://www.youtube.com/watch?v=jrHRe9lSqqA——「What Is a Prompt Injection Attack?」基礎概念。