Grok 加密提示注入攻擊：一個普通網頁點解可以偷走聊天資料？

Adversa AI 研究員 Rony Utevsky 揭示一種針對 Grok 網頁瀏覽代理的間接提示注入及資料外洩技術，並將其命名為 Cryptographic Context Injection。攻擊毋須使用者親自輸入任何惡意指令；只要叫 Grok 摘要或分析一個被預先動過手腳的網頁，代理便可能自行解密攻擊者指令、讀取目前對話可供使用的資料，再透過瀏覽工具向外傳送，而過程中未必出現明顯確認提示。

重點唔係 AES-256-GCM 被破解

這次問題並不是 AES-256-GCM 加密本身失效，而是出在 Grok 的安全檢查、程式碼執行環境和瀏覽工具之間的界線。

惡意網頁會同時放入加密指令、解密所需的資料，以及要求 Grok 執行解密程序的步驟。Grok 初步檢查網頁時見到的只是一段密文，未能直接讀出當中的惡意命令。當使用者要求它摘要網頁，代理便可能按照頁面指示，在 Python 或程式碼執行沙盒內運行解密程序。

解密後的指令再以「工具輸出」形式回到模型上下文。問題在於，代理可能會將工具產生的內容視為操作結果，而不是仍然屬於不可信的網頁內容；攻擊者控制的指令就此被「洗」入一個較受信任的處理階段。

Adversa 表示曾以 grok.com 上的 Grok 4.5 Fast 測試這種方法。另一份測試報道指，研究人員在 2026 年 6 月至 8 月期間嘗試 20 次，成功率為 40%。這個數字只反映研究人員測試環境的結果，並不代表每次攻擊或每個 Grok 對話都一定會成功。

攻擊流程可以點樣運作？

報告所描述的攻擊鏈大致分為以下幾步：

1. 網頁藏入加密載荷。 攻擊者在一個表面上普通的網頁內放入密文、解密指示和金鑰資料。相關示範使用 PBKDF2 衍生金鑰，以及 AES-256-GCM 加密。

2. 初步掃描睇唔到真正指令。 Grok 可以檢查網頁上可見的內容，但危險指令藏在加密資料之中。由於密文未能直接呈現原文，模型在第一輪掃描時難以判斷當中的命令。

3. 代理自己執行解密。 當使用者要求 Grok 摘要或分析該頁面，代理可能依照網頁指示，在程式碼執行環境內運行解密程序。

4. 解密指令重新進入上下文。 原本由攻擊者控制、來自不可信網頁的內容，變成工具操作的輸出結果。這造成來源追蹤問題：代理未必再以同樣嚴格的標準看待它。

5. 讀取目前工作階段可用的資料。 在概念驗證示範中，解密後的指令要求 Grok 取得使用者名稱、概略位置、訂閱級別，以及目前對話上下文內的提示或內容。

6. 利用瀏覽請求向外傳送。 Grok 隨後開啟攻擊者控制的網址，將收集到的資料放入 URL 查詢參數。Adversa 的示範稱，這個傳送過程沒有額外確認步驟，亦沒有顯眼警告。

不過，資料範圍要講清楚：現有證據支持的是代理在目前工作階段可以取得的提示及上下文。報道所講的「完整聊天紀錄」，不應自動理解成可以讀取使用者帳戶內所有歷史對話；示範主要涉及當前工作階段向代理開放的內容。

何時向 xAI 報告？目前有冇修補？

Adversa 表示，研究團隊已於 2026 年 6 月 3 日 透過 HackerOne 向 xAI 報告問題，並於 8 月 4 日 及 8 月 10 日 再次跟進披露協調事宜。

截至 2026 年 8 月 19 日，Adversa 稱仍未收到 xAI 的實質回覆，而且在 Grok 上仍可重現攻擊。當時的相關報道指，問題尚未有已部署的修補程式、公開 CVE 編號或面向使用者的臨時解決方法。

這個狀態是研究團隊及媒體根據披露過程作出的報告，並不是 xAI 發出的正式公開安全公告。現有資料亦未能證明有人已經利用這種方法，在研究人員示範以外攻擊真實使用者。

點解加密內容會造成防護盲點？

傳統提示注入防護通常集中尋找外部內容中的可疑字眼或指令。但這種攻擊將危險指令推遲到後續處理階段，避開最初的內容檢查。

模型在第一次掃描網頁時，不需要理解惡意命令；它只需要相信一個看似有用的要求，例如「執行解密程序以閱讀完整內容」。當程式碼執行環境完成解密，指令才變得可讀。此時代理可能已經同時擁有私人對話上下文、瀏覽權限，以及發出網絡請求的工具能力。

所以，這不只是關鍵字過濾做得唔夠好，而是典型的 AI 代理架構問題。當一個代理可以閱讀外部內容、執行程式碼、存取工作階段資料及呼叫網絡工具，惡意內容便可能將這幾項能力串連成資料外洩通道。

Grok 個案反映更大的 AI 代理風險

這次披露並非孤立事件。近年多項研究都指向同一個模式：攻擊者未必要直接破解模型或作業系統，只要提供代理原本就被設計去閱讀的內容，再利用代理自身的權限取資料、呼叫工具、改變狀態或發出網絡請求。

• Microsoft 365 Copilot 的 EchoLeak： 相關個案研究記錄了一個零點擊提示注入漏洞，攻擊者只需發送特製電郵，便可能透過遠端、未經驗證的方式外洩資料；漏洞編號為 CVE-2025-32711。
• Microsoft Copilot Personal 的 CoSnitch： Varonis 研究人員表示，持續操控 Copilot 的推理過程，可能令敏感資料被傳送到外部伺服器，並污染持久記憶。
• AI 編程代理的 TrustFall： Adversa 早前研究指出，惡意程式碼儲存庫設定可能令 Claude Code、Gemini CLI、Cursor CLI 及 GitHub Copilot CLI 透過攻擊者控制的 MCP 伺服器執行命令。

共同問題是：AI 代理不再只是「讀完內容再回答」，而是可以代表使用者採取行動。當不可信內容可以影響它的工具選擇，而代理又能接觸私人資料或執行程式碼，原本普通的摘要任務就可能變成資料外洩，甚至進一步演變成系統層面的攻擊。

今次披露帶出的防禦方向

單靠加強提示注入過濾器並不足夠。AI 代理至少需要以下幾類控制：

• 清楚分開內容來源： 在技術及介面上分隔網頁內容、工具輸出、系統指令和可信的應用程式狀態。
• 限制程式碼執行： 不應讓外部內容隨意觸發解密或其他程式碼；即使要執行，也應受嚴格政策及沙盒限制。
• 實施最小權限原則： 只向代理提供完成任務所需的私人上下文，避免普通摘要工作接觸不相關的對話資料。
• 敏感操作要求明確批准： 任何包含使用者資料或對話內容的網絡請求，都應要求使用者作出真正知情、清楚的確認。
• 控制外發流量： 透過網域白名單、代理伺服器檢查及出口流量控制，阻止代理向任意網址傳送上下文資料。
• 監察工具鏈： 對「讀取網頁 → 執行程式碼 → 擷取上下文 → 開啟外部網址」等異常連續操作記錄及發出警報。

最核心的教訓好直接：工具輸出的內容，唔會因為係工具產生，就自然變成可信指令。就 Grok 的示範而言，攻擊者將一個網頁變成解密及執行工作流程，再借用代理本身的權限，將私人上下文帶離原本的對話工作階段。