plaincve:~$

// 威脅簡報

CVE-2026-12537

Gemini CLI 在 CI 中自動信任工作目錄:外部 PR 裡的 .gemini/.env 可在沙箱啟動前於主機執行指令

CVSS
7.8 HIGH
CISA KEV
未列入
弱點類型
CWE-78 · CWE-20
主題
供應鏈 · AI 安全

PlainCVE 團隊 · 發布 2026-09-24 · AI 輔助 · 媒體簡報 ↓

人工審稿 2026-09-24指令測試:未提供漏洞重現:未進行驗證紀錄 ↓

Gemini CLI 在 CI 無人值守模式下自動信任工作目錄,外部 PR 夾帶的惡意 .gemini/.env 可在沙箱啟動前於主機上執行指令。

誰會中在 CI(自動化建置)中以無人值守模式執行 Gemini CLI 穩定版 0.39.1 以前或預覽版 0.40.0-preview.3 以前(含 0.40.0-preview.2)或 run-gemini-cli GitHub Action 0.1.22 以前版本,而且會處理外人可影響的內容(例如外部貢獻者的 PR)的工作流程。一般互動式使用不在此列。
後果如果條件成立,攻擊者可以在建置主機上執行指令,進而接觸該工作流程能存取的密鑰、憑證與原始碼。目前沒有來源回報已遭實際利用。
現在該做什麼把 Gemini CLI 升級到 0.39.1(或 0.40.0-preview.3),Action 升級到 0.1.22;有固定 gemini_cli_version 的工作流程要手動調高版本。只在工作流程只處理可信內容時才開啟「信任工作目錄」設定。
查看依據(4)
  • 廠商 / 維護者Google 公告:固定 gemini_cli_version 的工作流程要升級到修補版本,並檢查相關設定you are encouraged to upgrade to one of the patched versions and audit the workflow settings that use Gemini CLI.github.com
  • 廠商 / 維護者Action 信任指引:處理不可信內容的工作流程要採最小權限,並優先由維護者手動觸發Grant only the minimum privileges necessary for the workflow to complete its task.github.com
  • 研究團隊Pillar 另建議依 author_association 過濾 AI 工作流程的觸發者any issues:opened event without an author_association gate is a prompt injection surface.pillar.security
  • 本站判斷檢查外部 PR 是否動過 .gemini/、輪替受影響工作流程能碰到的密鑰,是本站的推論;官方沒有發布入侵指標或偵測指引
受影響版本Gemini CLI 0.39.1 以前,以及 0.40.0-preview.2;run-gemini-cli Action 0.1.22 以前
查看依據:來源說法不一(4)
  • CVE 紀錄說法不一CVE 紀錄:Gemini CLI 0.39.1 以前與 Action 0.1.22 以前,在無人值守的 CI 上受影響;預覽版只寫「< 0.39.1」Google Gemini CLI (versions prior to 0.39.1) and run-gemini-cli GitHub Action (versions prior to 0.1.22) on headless CI platformscveawg.mitre.org
  • 漏洞資料庫說法不一NVD 的受影響設定另外列出 0.40.0-preview.2,和 CVE 紀錄的寫法不同"criteria":"cpe:2.3:a:google:gemini-cli:0.40.0:preview2:*:*:*:node.js:*:*"services.nvd.nist.gov
  • 廠商 / 維護者Google 公告:舊版在 CI 無人值守模式下自動信任工作目錄,並載入其中的設定與環境變數In previous versions, Gemini CLI running in CI environments (headless mode) automatically trusted workspace folders for the purpose of loading configuration and environment variables.github.com
  • 本站判斷公告說變更「影響所有」Action;要真的被利用仍需工作流程處理不可信內容,這是本站的解讀,不是 Google 的說法
修好的版本Gemini CLI 0.39.1、0.40.0-preview.3 以上;run-gemini-cli Action 0.1.22 以上
查看依據(3)
  • 廠商 / 維護者Google 公告:修補在 Gemini CLI 0.39.1 與 0.40.0-preview.3The folder trust and tool allowlisting mitigations are available in @google/gemini-cli version 0.39.1 and 0.40.0-preview.3.github.com
  • 廠商 / 維護者Google 公告:Action 沒有固定 gemini_cli_version 時,預設會使用最新的 CLIBy default, the run-gemini-cli GitHub Action will receive and run the latest version of gemini-cli.github.com
  • 廠商 / 維護者修補 PR #25814:不可信的工作目錄不再載入 .env,無人值守模式遇到不可信資料夾會停止執行In headless mode, execution is now blocked if the current directory is untrusted.github.com
CVSS 向量
顯示完整向量CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
時間點
  • 漏洞出現 2025-06-25 · 首版 0.1.0 發布（受影響範圍自 0 起） 來源
  • 首次公開 2026-04-24
CISA KEV未列入(未列入 KEV 不代表沒有被利用)
查看依據(2)
  • 本站判斷本站 2026-09-24 的 CISA KEV 快照沒有這個 CVE;未列入不代表沒有被利用
  • 本站判斷研究時沒有找到任何來源回報這個漏洞遭實際利用

藍隊應對手冊

確認、修補 / 緩解、應變、強化。版本符合受影響條件不等於已被入侵;檢查沒有結果也不等於安全,每一項都有能證明與不能證明的範圍。標記的步驟對應下方攻擊流程裡可以擋下攻擊的那一步。

DETECT確認我受影響嗎?有沒有入侵跡象?
  1. 01找出使用 run-gemini-cli 的工作流程與固定版本

    Action 低於 0.1.22,或 gemini_cli_version 固定在 0.39.1 以前,就要處理。沒有設定 gemini_cli_version 的工作流程,官方說會預設使用最新的已修補 CLI。

    唯讀查詢
    grep -rnE "run-gemini-cli|gemini_cli_version" .github/workflows/
    步驟 2步驟 3
  2. 02確認本機或映像檔裡的 Gemini CLI 版本

    穩定版低於 0.39.1、預覽版低於 0.40.0-preview.3(0.40.0-preview.2 也受影響),即屬受影響版本。

    唯讀查詢
    npm ls -g @google/gemini-cli
    步驟 3
  3. 03檢查外部 PR 是否動過 .gemini/

    官方沒有發布入侵指標或偵測指引;這是 PlainCVE 的建議:回顧對外部 PR 執行過的 CI 紀錄,並找出新增或修改 .gemini/ 目錄的 PR。

    唯讀查詢
    git log --all --oneline -- .gemini/
    步驟 1
MITIGATE修補 / 緩解先修補;還不能修補時先擋住
  1. 01升級 Gemini CLI 與 Action

    Gemini CLI 升到 0.39.1 或 0.40.0-preview.3,Action 升到 0.1.22;有固定版本的工作流程要調高並檢查設定。

    步驟 3步驟 4
  2. 02只對可信工作流程開啟「信任工作目錄」

    修補後 CI 預設不信任工作目錄。只有工作流程只處理可信內容時,才設定信任環境變數或 --skip-trust;變數名稱各來源不一致,請查你所用版本的文件。

    步驟 3
RESPOND應變發現入侵跡象時
  1. 01輪替受影響工作流程能碰到的密鑰

    如果受影響的工作流程曾對不可信 PR 執行,輪替它能存取的 token 與憑證。這是 PlainCVE 的推論,不是官方指引,也不代表已確認外洩。

    步驟 5
HARDEN強化長期避免同類問題
  1. 01不要自動對外部 fork 內容執行 AI 工作流程

    官方信任指引建議優先採用維護者手動觸發的流程;Pillar 另建議依 author_association 過濾觸發者。

    步驟 1步驟 2
  2. 02最小權限 token 與最少工具

    例如只給 issues: read,避免 actions: write 這類廣泛權限;只允許少量唯讀工具;處理不可信內容的 checkout 設 persist-credentials: false。

    步驟 5
完整修復步驟與說明
元件升級到
@google/gemini-cli(npm)0.39.1;預覽版用 0.40.0-preview.3
google-github-actions/run-gemini-cli0.1.22
  1. 這是會破壞相容性的變更。 升級後,CI 預設不再信任工作目錄。依賴工作區設定的流程會讀不到那些設定;如果資料夾不被信任,無人值守模式會以 FatalUntrustedWorkspaceError 結束。請先想好哪些工作流程只處理可信內容,再決定要不要開啟信任。
  2. 信任變數名稱請以你的版本文件為準。 公告與修補 PR 寫 GEMINI_TRUST_WORKSPACE,現行 CLI 文件與 Action 信任指引寫 GEMINI_CLI_TRUST_WORKSPACE;另有 --skip-trust 參數。目前版本接受哪一個,我們無法確認。
  3. 不要為了讓流程恢復運作,就對處理外部 PR 的工作流程開啟信任。 這等於把修補關掉。這類工作流程應先依官方信任指引強化(最小權限 token、手動觸發、只允許唯讀工具)。
  4. 修補後在不可信資料夾中,工作區 settings.json、.env、擴充套件管理、工具自動核准、自動載入記憶與脈絡、MCP 伺服器及自訂指令都會被擋下(官方文件)。

攻擊流程

從左到右是攻擊發生的順序。藍色盾牌代表這一步可以被擋下,越早擋下越好。點圖示可看細節。

Gemini CLI 在 CI 中自動信任工作目錄:外部 PR 裡的 .gemini/.env 可在沙箱啟動前於主機執行指令: 1. 攻擊者送出一個夾帶惡意 .gemini/.env 的 PR → 2. CI 工作流程以無人值守模式對這份 PR 執行 Gemini CLI → 3. 舊版在 CI 中自動信任工作目錄,讀進專案的 .env → 4. 容器啟動器在沙箱啟動前使用這些值,在主機上執行指令 → 5. 攻擊者接觸工作流程可存取的密鑰與原始碼CVE-2026-12537 · Gemini CLI 在 CI 中自動信任工作目錄:外部 PR 裡的 .gemini/.env 可在沙箱啟動前於主機執行指令攻擊者你的系統攻擊者送出一個夾帶惡意 .gemini/.env 的 PR — 不需要是專案成員,只要能對倉庫送 PR 或以其他方式影響工作目錄內容。 1攻擊者送出一個夾帶惡意.gemini/.env 的 PRCI 工作流程以無人值守模式對這份 PR 執行 Gemini CLI — 例如透過 run-gemini-cli Action 自動審查 PR。 2CI 工作流程以無人值守模式對這份 PR 執行Gemini CLI舊版在 CI 中自動信任工作目錄,讀進專案的 .env — 互動模式會先詢問使用者是否信任資料夾,但無人值守模式跳過了這一步,直接讀取 .gemini/ 裡的環境變數等設定。 3舊版在 CI 中自動信任工作目錄,讀進專案的.env容器啟動器在沙箱啟動前使用這些值,在主機上執行指令 — 因為這一步發生在沙箱之外,沙箱無法提供保護。具體是哪個變數、如何被使用,官方未公開。 4容器啟動器在沙箱啟動前使用這些值,在主機上執行指令攻擊者接觸工作流程可存取的密鑰與原始碼 — 研究者 Novee 指出,這可能導致 token 被竊與供應鏈橫向擴散。 5攻擊者接觸工作流程可存取的密鑰與原始碼攻擊路徑可在此擋下PlainCVE · plaincve.date/vulns/cve-2026-12537-gemini-cli-headless-workspace-trust · CC BY 4.0
圖片可自由用於報導與教學,採 CC BY 4.0,圖上已附出處。
  1. 攻擊者

    攻擊者送出一個夾帶惡意 .gemini/.env 的 PR

    不需要是專案成員,只要能對倉庫送 PR 或以其他方式影響工作目錄內容。

    防禦: 不要讓 AI 工作流程對外部 fork 的內容自動執行;改由維護者手動觸發,或依 author_association 過濾。

  2. 你的系統

    CI 工作流程以無人值守模式對這份 PR 執行 Gemini CLI

    例如透過 run-gemini-cli Action 自動審查 PR。

    防禦: 依 Action 的信任指引,把非協作者的 issue 與 PR 視為不可信內容。

  3. 你的系統

    舊版在 CI 中自動信任工作目錄,讀進專案的 .env

    互動模式會先詢問使用者是否信任資料夾,但無人值守模式跳過了這一步,直接讀取 .gemini/ 裡的環境變數等設定。

    防禦: 升級到 Gemini CLI 0.39.1 / Action 0.1.22:不可信的資料夾不再載入 .env,無人值守模式會直接以錯誤結束。

  4. 你的系統

    容器啟動器在沙箱啟動前使用這些值,在主機上執行指令

    因為這一步發生在沙箱之外,沙箱無法提供保護。具體是哪個變數、如何被使用,官方未公開。

    防禦: 同上,升級是根本解法。

  5. 攻擊者

    攻擊者接觸工作流程可存取的密鑰與原始碼

    研究者 Novee 指出,這可能導致 token 被竊與供應鏈橫向擴散。

    防禦: 給工作流程最小權限的 token,處理不可信內容的 checkout 步驟設 persist-credentials: false,密鑰只放在 GitHub Secrets。

影響範圍

條件是否受影響
Gemini CLI 穩定版 0.39.1 以前、預覽版 0.40.0-preview.3 以前(含 0.40.0-preview.2),在 CI 無人值守模式下執行,而且攻擊者能控制工作目錄裡的設定檔(例如外部 PR 帶進的 .gemini/.env)受影響
run-gemini-cli Action 0.1.22 以前,而且它執行的受影響版本 CLI 跑在攻擊者能放入設定檔的工作目錄上(例如 checkout 外部 PR 的程式碼)受影響
工作流程只讀取 issue 或留言文字,工作目錄是自己的可信程式碼不符合本 CVE 的條件(需要不可信的 .gemini/.env);但同一份公告的 --yolo 工具允許清單問題可能適用,見下方
Gemini CLI 0.39.1、0.40.0-preview.3 以上;Action 0.1.22 以上已修補
Action 沒有設定 gemini_cli_version官方說會預設使用最新的已修補 CLI
在自己電腦上互動式使用 Gemini CLI互動模式本來就會先詢問是否信任資料夾,不屬於這個遠端情境
CI 工作流程只處理團隊自己的可信程式碼缺少攻擊者可放入檔案的入口,但仍建議升級

各來源對預覽版的描述不同:CVE 紀錄只寫「< 0.39.1」,NVD 另外列出 0.40.0-preview.2,GitHub 倉庫公告寫「< 0.40.0-preview.3」。

Google 公告說這次變更「影響所有」Gemini CLI GitHub Action。PlainCVE 的解讀是:這句話指的是所有使用者都會碰到的行為變更;要真的被利用,仍需要工作流程處理不可信的內容。這是我們的解讀,不是 Google 的說法。

原理

Gemini CLI 是 Google 的 AI 程式助理,可以在終端機裡讀寫程式碼,也能透過 run-gemini-cli Action 放進 GitHub 的 CI(程式碼變動時自動建置、測試的系統)裡,例如自動審查 PR。

專案可以在自己的 .gemini/ 資料夾裡放設定,包括 .env 檔(存放環境變數,也就是程式啟動時讀取的設定值)。因為這些設定來自程式碼本身,Gemini CLI 設計了「資料夾信任」:互動使用時,會先問你是否信任這個資料夾,不信任就不套用。

問題在於 無人值守模式(headless,也就是 CI 裡沒有人按確認的情況)直接把工作目錄當成可信。於是,外部貢獻者 PR 裡的 .gemini/.env 會被讀進來。CVE 紀錄指出,這些值會影響「容器啟動器」,也就是負責啟動沙箱的元件,而它在 沙箱啟動之前 就在主機上執行,所以沙箱來不及保護。結果是攻擊者可以在建置主機上執行指令。Novee 指出,這讓攻擊者能接觸工作流程可取得的密鑰、憑證和原始碼,進而竊取 token 或攻擊供應鏈。

簡單說:信任與否是依「執行模式」決定,而不是依「內容從哪裡來」決定。具體是哪個變數、如何被使用,官方沒有公開,本頁也不推測。

有問題的思路(概念示意,不是原始程式碼):

展開程式碼範例(python)
if headless_mode:
    trusted = True            # CI 裡直接當作可信
if trusted:
    load_env(workspace / ".gemini/.env")
launch_container()            # 沙箱啟動前在主機上執行,已受 .env 影響

修好的思路:

展開程式碼範例(python)
trusted = is_explicitly_trusted(workspace)   # 使用者明確設定才算
if not trusted:
    if headless_mode:
        raise FatalUntrustedWorkspaceError   # 直接停止
    # 不載入 .env、工作區設定、MCP 伺服器等
else:
    load_env(workspace / ".gemini/.env")
launch_container()

同一份公告裡的另一個問題(不屬於本 CVE): Google 的公告 GHSA-wpqr-6v78-jr5g 還提到 --yolo(自動核准)模式會忽略 ~/.gemini/settings.json 裡的工具允許清單,可能讓提示注入導致遠端執行程式。這部分主要由 Pillar Security 回報。CVE 紀錄的描述只涵蓋 .env 與容器啟動器的問題,本頁也只談這一項。部分二手來源(Novee 的漏洞頁、GitHub Advisory Database 的摘要)把兩者合在一起描述,請留意。

時間軸

日期事件
2026-04-16 至 04-20Pillar 回報 --yolo 相關的攻擊鏈(另一個問題),Google 停用有風險的工作流程
2026-04-23修補 PR #25814 合併
2026-04-24釋出 Gemini CLI v0.39.1 與 Action v0.1.22;GHSA 公開
2026-04-29 至 04-30Novee 發表文章;The Register、The Hacker News 報導(The Register 當時說尚未指派 CVE)
2026-06-17CVE 編號保留
2026-06-24GoogleCloud 公開 CVE
2026-07-02NVD 分析最後更新

Novee 回報的日期不明。

延伸閱讀

  • 評分差異: NVD 的 CVSS 3.1 為 7.8(判定為本機攻擊、需要使用者互動);Google(CNA)的 CVSS 4.0 為 10.0,GHSA 的 CVSS 3.1 也是 10.0(判定為可遠端、不需互動)。差異來自對「外部 PR 觸發 CI」這種情境的不同判斷。本頁的 severity 欄位採用 NVD 的分數。
  • CWE 不一致: CNA 標 CWE-20(輸入驗證不當),NVD 標 CWE-78(作業系統指令注入);CVE 描述本身的用字比較接近 CWE-78。GHSA 列了 CWE-20、77、78、200,涵蓋兩個問題。
  • CVE 對應: GHSA 頁面仍顯示「No known CVE」,但 CVE 紀錄唯一的參考連結就是這份 GHSA。
  • 致謝: GHSA 致謝 Elad Meged(Novee Security)與 Dan Lisichkin(Pillar Security);CVE 紀錄致謝 Elad Meged 與 Devansh Batham。後者與本 CVE 的關係未能確認。
  • 利用狀況: 目前沒有來源回報遭實際利用。提供給我們的紀錄說本 CVE 不在 CISA KEV,但研究時無法連上 CISA 網站獨立確認。
  • 官方沒有發布入侵指標;偵測與密鑰輪替建議屬於 PlainCVE 的推論。

驗證紀錄 已人工審稿、核對來源;尚未在我們的環境重現

人工審稿2026-09-24

驗證紀錄只寫環境與結果,不公開重現步驟或可攻擊他人系統的程式。詳見 政策.

來源

  1. 其他First version 0.1.0 published (affected range starts at 0) · registry.npmjs.org · 查閱 2026-09-24
  2. 安全公告GHSA-wpqr-6v78-jr5g — Update to Gemini CLI and run-gemini-cli Trust Model · Google (google-github-actions), 2026-04-24 · 查閱 2026-09-23
  3. 安全公告Gemini CLI: Remote Code Execution via workspace trust and tool allowlisting bypasses · GitHub Advisory Database, 2026-04-24 · 查閱 2026-09-23
  4. CVE / NVD / OSVCVE-2026-12537 record (CVE Services API) · CVE Program / GoogleCloud CNA, 2026-06-24 · 查閱 2026-09-23
  5. CVE / NVD / OSVCVE-2026-12537 (NVD API) · NIST NVD, 2026-06-24 · 查閱 2026-09-23
  6. 修補 commit / 版本feat(cli): secure .env loading and enforce workspace trust in headless mode (PR #25814) · Google (google-gemini), 2026-04-23 · 查閱 2026-09-23
  7. 修補 commit / 版本Comparing v0.39.0...v0.39.1 · Google (google-gemini), 2026-04-24 · 查閱 2026-09-23
  8. 修補 commit / 版本Release v0.39.1 · Google (google-gemini), 2026-04-24 · 查閱 2026-09-23
  9. 修補 commit / 版本run-gemini-cli Release v0.1.22 · Google (google-github-actions), 2026-04-24 · 查閱 2026-09-23
  10. 廠商說明Trusted Folders · Google (google-gemini) · 查閱 2026-09-23
  11. 廠商說明Trust Guidance · Google (google-github-actions) · 查閱 2026-09-23
  12. 廠商說明Best Practices · Google (google-github-actions) · 查閱 2026-09-23
  13. 研究文章Google Gemini CLI CVSS 10.0 RCE Vulnerability: Critical Security Advisory · Novee Security, 2026-04-29 · 查閱 2026-09-23
  14. 研究文章Update to Gemini CLI and run-gemini-cli Trust Model · Novee Security · 查閱 2026-09-23
  15. 研究文章My Agentic Trust Issues: From Prompt Injection to Supply-Chain Compromise on gemini-cli · Pillar Security, 2026-05-05 · 查閱 2026-09-23
  16. 新聞報導Google fixes CVSS 10.0 vulnerability in Gemini CLI · The Register, 2026-04-30 · 查閱 2026-09-23
  17. 新聞報導Google Fixes CVSS 10 Gemini CLI CI RCE and Cursor Flaws Enable Code Execution · The Hacker News, 2026-04-30 · 查閱 2026-09-23

媒體簡報

一句話

Google 的 AI 程式助理 Gemini CLI 及其 GitHub Action 在 CI(自動化建置)中會自動信任正在處理的程式碼資料夾。因此,外人送來的 PR 只要夾帶一個設定檔,就可能在沙箱啟動前於建置主機上執行指令。Google 已在 2026 年 4 月 24 日釋出 Gemini CLI 0.39.1 與 Action 0.1.22 修補。目前沒有來源回報遭實際利用,本漏洞也不在美國 CISA 的已知遭利用清單中。

關鍵數字

嚴重度(NVD)
CVSS 3.1 7.8 services.nvd.nist.gov
嚴重度(Google,CNA)
CVSS 4.0 10.0 cveawg.mitre.org
修補版本
Gemini CLI 0.39.1 / 0.40.0-preview.3;Action 0.1.22 github.com
安全公告公開
2026-04-24(GHSA-wpqr-6v78-jr5g) github.com
CVE 公開
2026-06-24 cveawg.mitre.org

已確認

  • 舊版在無人值守的 CI 模式下自動信任工作目錄,並讀取 .gemini/ 內的設定(Google 公告)。
  • 惡意 .gemini/.env 可經由容器啟動器,在沙箱啟動前於主機執行程式(CVE 紀錄)。
  • 修補後 .env 只在可信工作目錄載入,無人值守模式遇到不可信資料夾會直接結束(修補 PR #25814)。

尚未確認 / 說法不一

  • 評分差異大:NVD 評為本機、需使用者互動的 7.8,Google 評為可遠端、無需互動的 10.0。
  • 信任環境變數名稱:公告寫 GEMINI_TRUST_WORKSPACE,現行文件寫 GEMINI_CLI_TRUST_WORKSPACE;目前版本接受哪個未確認。
  • 致謝名單不一致:GHSA 列 Elad Meged 與 Dan Lisichkin,CVE 紀錄列 Elad Meged 與 Devansh Batham。
  • 具體是哪個環境變數、啟動器如何使用它,沒有公開說明。

可引用的一句話

AI 代理被請來審查陌生人的程式碼,卻先照著那份程式碼裡的設定行事。

圖片

下載分享圖(PNG) · 攻擊流程圖(可下載)

引用時請標示「PlainCVE」並附上本頁連結。 完整引用格式見下方「如何引用本頁」。有事實錯誤請回報.

如何引用本頁

本文採 CC BY 4.0,轉載請保留署名與連結。

PlainCVE 團隊(2026)。《Gemini CLI 在 CI 中自動信任工作目錄:外部 PR 裡的 .gemini/.env 可在沙箱啟動前於主機執行指令》。PlainCVE。https://plaincve.date/vulns/cve-2026-12537-gemini-cli-headless-workspace-trust(查閱日期:YYYY-MM-DD)
BibTeX
@misc{cve202612537geminicliheadlessworkspacetrust2026,
  title  = {Gemini CLI 在 CI 中自動信任工作目錄:外部 PR 裡的 .gemini/.env 可在沙箱啟動前於主機執行指令},
  author = {PlainCVE 團隊},
  year   = {2026},
  howpublished = {PlainCVE},
  url    = {https://plaincve.date/vulns/cve-2026-12537-gemini-cli-headless-workspace-trust},
  note   = {更新於 2026-09-24}
}