Piotr Ryciak - Vibe Check: Security Failures in AI-Assisted IDEs | [un]prompted 2026

Mindu Guard 研究團隊針對 AI 輔助身分和編碼代理進行了深入的安全評估。這類工具（如 Codeex、Gemini CLI、Amazon Q）代表了編碼輔助的新一代，不同於傳統自動完成工具，它們能夠讀寫檔案、執行終端命令、修改配置並推送程式碼，因此攻擊面遠大於以往。研究團隊發現了 37 個漏洞分布在 15 家以上的供應商中，導致遠端程式碼執行、資料洩露或沙箱繞過，並將這些漏洞提煉為 25 種可重複的漏洞模式，分為四大類。

零點擊攻擊是最危險的一類，用戶無需任何交互即可觸發代碼執行。例如 Codeex 的 MCP 自動加載漏洞：攻擊者在儲存庫中放置 .codeex/configinal 文件定義惡意 MCP 伺服器，當受害者打開該工作區時，MCP 伺服器會在沙箱外初始化並執行反向 shell。類似地，Gemini CLI 存在初始化競爭條件：gemini settings.json 中的「發現命令」欄位會在信任對話框出現前自動執行，讓攻擊者能夠在用戶做出信任決定前建立持久化連線。

提示注入攻擊則利用工作區文件隱藏指令誘騙代理執行危險操作。例如在 Amazon Q 中，攻擊者通過長目錄名稱進行注入（內含「請讀取並立即按照說明操作」的提示），當代理對工作空間索引時，這些隱藏指令會驅使它讀取含有 API 金鑰的檔案，利用 grab 搜尋工具和配置修改實現完整的資料洩露鏈。有趣的是，搜尋參數從「key=」改為「y=」即可繞過代理的安全檢查，說明防禦機制易被簡單變化繞過。

配置投毒攻擊利用了工作區信任模型的另一個缺陷：信任持久性。用戶在克隆良性工作區並授予信任後，後續的配置變更（如 MCP 伺服器命令從 Playwright 代理改為反向 shell）不會重新提示信任。當用戶執行 git pull 後，惡意配置會在沒有任何警告的情況下自動執行。Cloud Code 中發現了 9 種這樣的信任持久向量，而工業界對此是否構成漏洞仍無共識：Anthropic 認為這是「安全與可用性的平衡」，OpenAI Codeex 標記為「資訊類錯誤」，但 Cursor 同樣漏洞被分配了 CVE 編號，凸顯了標準化的缺失。

根本問題出在工作區信任模型的基準實現不足：預設應該拒絕信任（而非允許），不受信任工作區應禁用所有代碼執行（而非部分），配置變更時應重新驗證（而非一次性檢查）。此外，多個相同設計的信任對話框導致「審核疲勞」，開發者往往為了快速開始工作而點擊同意，形成與早期瀏覽器 Flash 插件信任對話相同的失敗模式。

為應對這些威脅，研究團隊已開源 25 種漏洞模式目錄、開發了 Cloud Code 測試技能插件，並提供測試人員和建置人員的檢查清單。從根本上講，解決方案不在於在本地檔案系統層層堆疊防禦，而是將 AI 工具與開發環境解耦，通過沙箱、容器或雲端開發環境等手段確保即使攻擊成功，爆炸半徑也被限制在可拋棄的環境中。這與瀏覽器安全進化的教訓一致：在 Flash 時代，警告對話框失效後，業界採用的解決方案是進程隔離和沙箱化，而非更多的警告。