Gemini CLI高危漏洞：CI/CD管道如何變成攻擊通道

「這個漏洞讓未授權的外部攻擊者能強制加載惡意配置，在沙盒初始化前就在主機系統上執行命令。」Novee Security 在周三的報告中這樣描述。CVSS 評分 10.0，沒有 CVE 編號，影響 Google 的 Gemini CLI 工具鏈——包括 npm 包和 GitHub Actions 工作流。問題出在「無頭模式」（headless mode）下對文件夾的自動信任機制。

正方觀點：這是一個設計層面的權限失控

漏洞的核心邏輯很清晰。Gemini CLI 在 CI 環境（無頭模式）運行時，會自動信任當前工作區文件夾，以便加載配置和環境變量。這意味著工具會不加審查、不經沙盒、無需用戶明確同意，直接加載找到的任何代理配置。

攻擊路徑由此形成：攻擊者向倉庫提交包含惡意 `.gemini/` 目錄的拉取請求，其中放置精心構造的環境變量和配置文件。CI 流水線觸發后，Gemini CLI 自動信任該目錄，加載惡意配置，最終在主機上執行任意代碼。

Google 的修復方案印證了這一判斷。0.39.1 版本強制要求文件夾必須顯式信任后才能訪問配置文件。同時，`--yolo` 模式下的工具白名單機制也被收緊——此前該模式會忽略 `~/.gemini/settings.json` 中的白名單，自動運行所有工具調用（包括 `run_shell_command`），現在策略引擎會強制評估白名單。

這兩個改動都指向同一個方向：把「默認開放」改為「默認拒絕」。原設計假設 CI 環境是相對可信的，但實際場景中，處理用戶提交內容的流水線（如 PR 審查）恰恰是高風險場景。

反方觀點：影響范圍被過度放大，實際利用有條件

Google 在公告中明確劃定了影響邊界：僅影響無頭模式下的工作流，且需要配合「不受信任的文件夾內容」才能觸發遠程代碼執行。如果 Gemini CLI 用于本地交互式會話，用戶會收到明確的信任提示，攻擊鏈無法自動完成。

修復后的配置成本也值得關注。Google 警告：「一些此前依賴舊行為的工作流可能會靜默失敗，除非修改工具白名單以適應任務。」這意味著安全加固是有代價的——自動化程度降低，需要人工介入審查信任機制。

更深層的質疑是：CVSS 10.0 的評分是否反映了真實風險？該漏洞尚無 CVE 編號，評分來源是 Novee Security 的獨立評估而非官方機構。CVSS 3.1 標準下，10.0 分要求「網絡可訪問、低攻擊復雜度、無需權限、完全影響機密性/完整性/可用性」。雖然技術層面滿足這些條件，但實際利用需要攻擊者能夠向目標倉庫提交內容，這屬于供應鏈攻擊的前置條件，并非所有 CI/CD 流水線都暴露于此。

我的判斷：AI 編碼工具的安全模型正在經歷壓力測試

這個漏洞的真正價值不在于技術細節，而在于它揭示了 AI 輔助開發工具的一個結構性張力：「智能代理」需要廣泛權限才能高效工作，但廣泛權限在自動化場景中極易被濫用。

Gemini CLI 的設計初衷是減少開發者的重復操作。自動信任工作區、自動加載配置、`--yolo` 模式自動執行命令——這些功能在交互式環境中提升效率，移植到 CI/CD 場景后卻成為攻擊面。這不是簡單的「配置錯誤」，而是產品功能與安全邊界的錯配。

Google 的修復策略提供了觀察窗口。他們沒有取消無頭模式或 `--yolo` 模式，而是增加顯式信任環節和白名單強制評估。這暗示了產品定位：CI/CD 場景是核心用例之一，不能因安全而犧牲自動化，但必須把「信任決策」從隱式變為顯式。

對比同類工具，Cursor 近期也被 Novee Security 曝出類似問題——提示詞注入可導致代碼執行。兩家公司的應對邏輯趨同：AI 編碼代理的權限邊界需要重新設計，不能再假設「能訪問代碼 = 可以執行任意操作」。

對技術團隊的具體建議：審計現有 CI 流水線中 Gemini CLI 的使用場景，確認是否涉及處理外部提交的 PR；升級至 0.39.1 后測試工作流，關注「靜默失敗」的潛在影響；評估 `--yolo` 模式的工具白名單，最小化授權范圍。