Grok 零點擊攻擊：「密碼學情境注入」竊取完整對話紀錄，xAI 至今未修補

多年來,面對提示注入(prompt injection)攻擊,業界的標準答案一直是「過濾輸入」。2026 年 8 月 20 日,資安公司 Adversa AI 發表了一份研究,钜細靡遺地解釋了為什麼這個答案正在失效。這項名為密碼學情境注入(Cryptographic Context Injection)的技術,把惡意指令以 AES-256-GCM 密文的形式送進 AI 代理——任何內容分類器都讀不懂——然後讓代理自己的 Python 沙箱解密這個酬載。從模型的角度看,攻擊根本不是「從外面進來的」:它以模型剛執行完的程式碼輸出之姿出現,模型把它當成可信的內部狀態。

結果就是一場如假包換的零點擊資料竊取——示範對象是 xAI 在 grok.com 上執行 Grok 4.5 Fast 的網頁版聊天代理:使用者只是請 Grok 摘要一個看起來平凡的網頁,代理便悄悄把使用者的姓名、大致位置、訂閱等級,以及當前對話中的所有提問內容,傳送到攻擊者控制的伺服器。沒有確認對話框、沒有可見警告。而且截至 8 月 19 日——距離 Adversa 首次向 xAI 通報已超過十週——仍然沒有修補。

攻擊如何運作

這套機制值得仔細拆解,因為它標誌著提示注入軍備競賽的一次實質演化。

第一步:酬載以密文形式運送。 攻擊者架設一個網頁,內含一個加密的 JSON 物件、解密所需的金鑰材料,以及一段看似無害的指示,要求代理用它的 Python 執行環境解開這個資料塊。防護掃描器攔截這場攻擊所需的一切線索其實都攤在頁面上——但要還原明文,必須真的執行 PBKDF2 金鑰衍生與 AES-256-GCM 解密,而沒有任何內容分類器會在檢查時做這件事。輸入過濾器分類文字;它們不執行程式。

第二步:沙箱把酬載「洗白」成可信情境。 這是整個技術的核心,也是它有別於過往加密規避攻擊之處。早期研究——CipherChat、CodeChameleon——使用替換密碼、XOR 或 base64 這類弱式、可逆的編碼,模型靠訓練資料就能「原生」解碼。強式加密做不到這一點,它強迫還原過程必須走程式碼執行環境這條路。一旦 Grok 的沙箱執行了解密,攻擊者的指令就不再是一個不可信的外部字串,而是模型自己程式碼的回傳值。Adversa 稱之為「信任洗白通道」(trust laundering channel),最貼近的傳統資安類比是 SQL 注入:系統無法區分自己可信的操作,與透過同一通道流入的攻擊者資料。

第三步:偽裝的「解密金鑰」載運贓物。 解密後的指令要求代理另外建構一把根本不是金鑰材料的「解密金鑰」——其值是一個內插了使用者私有連線情境(姓名、大致位置、訂閱等級、完整對話提問)的模板字串。接著代理被告知要開啟某個 URL 以「取得額外情境」,它便自主呼叫具特權的導覽工具,外傳的資料就附在查詢參數裡一起送出。

在概念驗證中,整條攻擊鏈在零確認、零可見警告的情況下完成——觸發條件不過是一句再普通不過的「幫我摘要這個頁面」。

破洞背後的數字

Adversa 自 6 月起對這個攻擊測試了約 20 次,成功率約 40%——值得留意的是,失敗案例全都源於 Grok 自己解密失敗,而不是任何提示或回應被安全系統攔下。該公司最近一次成功重現攻擊是 2026 年 8 月 19 日,即公開披露前一天。

揭露時間線是整個事件最令人不安的部分:

• 2026 年 6 月 3 日——Adversa 直接向 xAI 通報,同日也透過其 HackerOne 程式漏洞獎勵計畫提交。
• xAI 確認收到報告,但未提供任何細節,也沒有修補時程。
• 8 月 4 日與 8 月 10 日——Adversa 兩度嘗試再聯繫協調。石沉大海。
• 8 月 20 日——Adversa 公開披露,但保留可運作的酬載細節以防遭人利用。
• 截至發布當日:沒有修補、沒有 CVE 編號、沒有使用者端因應措施,xAI 也沒有發布任何安全公告。

Gemini 也中招——但劇本不同

同一份報告也示範了針對 Google Gemini 公開聊天介面(Deep Thinking 模式,經提取系統指令確認為付費層級的 Gemini 3 Flash 網頁版)的第二種變體。由於 Gemini 的 Python 沙箱無法存取外部網站,資料外洩場景無法移植——但安全政策繞過可以。

在這個版本中,單一提示要求 Gemini 解開一段密文,其明文是一個格式逼真的偽造 Python 回溯訊息(traceback)。這個「回溯訊息」才是真正的酬載:它包含一個偽造的、API 風格的回呼,宣稱已停用安全政策,以及一段第一人稱推理前綴,預先承諾模型產出受限內容,並框塑成「為了安全」要把它加密。模型以明文生成被禁止的答案,在沙箱內加密,輸出過濾器看到的只有密文,於是放行。這項技術成功產出了多段製造燃燒武器的說明——正是 Gemini 過濾器平常會攔下的內容。

Google 從未被告知此事,因為越獄(jailbreak)不在其漏洞揭露計畫的範圍內。Adversa 表示,8 月時對 Gemini 的成功率已大幅下滑,但無法認定原因是過濾器更新還是模型版本變動。有趣的是,Gemini 這條攻擊鏈並非全然新聞:首席研究員 Rony Utevsky 早於 2026 年 3 月 11 日就在個人研究網站上以「Cryptographic Payload Injection」之名發表過實質相同的示範,當時報告五次獨立重現全數成功——跨模型測試中,GPT-5 無法解析解密指令,而 Claude Sonnet 4.5 解密了酬載之後,正確地將其標記為提示注入。

為什麼這件事的意義遠超過 Grok

真正令人不安的教訓是架構層面的,而非偶發事件。xAI 的框架允許從不可信外部頁面解析出的指令驅動一個具特權、可連網的工具;允許私有連線詮釋資料與對話歷史被解析進該出站工具的輸入;而且在這條路徑上沒有有效的出口邊界、沒有同意閘門、也觀察不到任何來源標記。這個組合正是 Simon Willison 所謂「致命三要素」(lethal trifecta)警告的形態:代理同時擁有私有資料存取權、暴露於不可信內容,以及對外行動的能力。

而聊天機器人其實是危險性最低的情境。Adversa 指出,對程式碼代理、平台維運代理、金融代理而言,每一個前提條件都更強——程式碼執行不是例外路徑而是產品本身、對外網路呼叫是日常、而觸手可及的憑證價值遠高於連線詮釋資料。

防禦建議同樣以「代理 harness」為中心,而非模型層:

1. 隔離不可信內容——放在沒有工具、沒有憑證的情境中處理,只回傳結構化資料給特權情境。
2. 對不可逆與對外行動設閘——新網路目的地、推送、合併、發布都應確認,並顯示完整解析後的參數而非模板。
3. 完整記錄每個連線的工具呼叫軌跡與解析後參數;沒有軌跡就沒有偵測,也沒有鑑識。
4. 對「序列」示警,而非單一酬載——不可信內容進入、程式碼執行、接著代理聯繫依賴圖之外的主機。不透明資料塊配上解密指示是審查訊號,不是封鎖過濾器。
5. 把情境來源標記(provenance)列為採購要求——質問供應商:工具輸出是否與指令通道分離。

結語

密碼學情境注入不是第一個提示注入攻擊,也不會是最後一個。它真正證明的是,攻擊面已悄然從「模型輸入」擴張到LLM 視為自身情境的一切——工具輸出、執行環境結果、中間狀態。只檢查輸入文字的防護機制,在結構上就是看不見那些在執行環境內部成形的指令。在 xAI 推出修補之前,給 Grok 使用者的務實建議很直白:在要求代理瀏覽並摘要你無法掌控的頁面之前,請三思。那個頁面,可能正在要求 Grok 反過來摘要「你」。