GitLab 的 AI Gateway 讓精心設計的 Flow 設定得以逃脫其提示沙箱

2026年10月2日，GitLab 為其 AI Gateway 發布了重大修補發行版——這個中介軟體負責在 GitLab 執行個體與其 Duo 功能所呼叫的語言模型之間傳遞請求——並指定為 CVE-2026-90970，評分為 10 分中的 9.9 分。用 GitLab 自己的話來說，這個漏洞可能允許「具備 Duo Agent Platform 存取權的已驗證使用者，透過特製的流程設定逃逸提示範本沙箱，導致在 AI Gateway 上執行任意命令」。只有執行自行託管 AI Gateway 的組織需要採取行動：GitLab 已經修復其為 GitLab.com、GitLab Dedicated，以及使用 GitLab 託管閘道的自管理客戶所營運的閘道，並在安全公告中如此說明。GitLab 的通知並未表示該漏洞曾被利用，而美國網路安全暨基礎設施安全局同日隨 CVE 記錄附加的評估，將利用情況列為「無」。這項發現的功勞歸給 HackerOne 上名為 invisiblemeerkat 的研究人員。 GitLab 的安全公告、NVD 記錄以及後續報導，對於該漏洞是什麼以及哪些版本含有該漏洞彼此一致；它們對於未知之事也同樣一致，也就是是否曾有人利用過它。這筆記錄與其他已記錄的代理基礎設施漏洞並列，這些漏洞收錄於 AI 事件檔案，其中每筆項目都帶有自己的來源、嚴重性、信心等級與爭議標記。

這份公告實際上說了些什麼，又遺漏了什麼

這份公告很短。它發布於 GitLab 的文件網站，標題為「GitLab AI Gateway 重大修補程式發行：19.2.4、19.3.2 與 19.4.1」，列出一個安全性修正，標題為「自訂流程提示範本中的不當中和問題影響 AI Gateway」，並標示為重大。它將 CVSS 3.1 向量列為 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H——可經網路觸達、攻擊複雜度低、所需權限低、無需使用者互動、範圍已變更，以及對機密性、完整性與可用性有高影響。這個向量值得一讀，因為它對攻擊者的描述很精確：權限低，但終究還是權限。公告只說「具備 Duo Agent Platform 存取權的已驗證使用者」，就沒有下文。它並未指明角色、權限，或它自己那句「在某些條件下」所指的條件。

它並未公布概念驗證，也未描述特製的流程配置，亦未為無法立即更新的閘道提供變通方案。Hacker News 在 10 月 2 日的報導中指出同樣的缺漏，並補充了一項在營運上至關重要的問題：該公告未提供任何方法，用以檢查閘道在修補前是否曾遭攻擊。Security Affairs 於隔日撰文，也記錄了相同的缺口。

附加於此 CVE 的常見弱點列舉項目是CWE-1336，即模板引擎中所用特殊元素的不當中和。GitLab 的公告從未使用 Jinja 這個詞。AI Gateway 自身的儲存庫文件則有：其提示註冊表文件描述提示設定檔「支援多種角色（例如使用者和系統）的 Jinja 表達式」，並描述一個 Prompt 類別「使用 Jinja 以輸入引數對提示模板進行插值」。此 CVE 所描述的缺口，正是該類引擎聞名的那一個——使用者提供的文字進入到會被求值而非印出的模板。

為什麼在這台特定主機上的一個指令值得 9.9

AI Gateway 不是 sidecar。根據 GitLab 的自架文件，它會接收來自 GitLab 的請求、組裝提示詞，並與模型後端通訊，例如 vLLM 伺服器、Amazon Bedrock、Azure OpenAI 或外部供應商；在完全自架的部署中，它正是讓提示詞與回應留在組織自身網路內的元件。GitLab 的 AI Gateway 安裝指南也告訴管理員產生簽署金鑰對，並將金鑰對的兩部分以環境變數傳給服務，分別命名為 AIGW_SELF_SIGNED_JWT__SIGNING_KEY 與 AIGW_SELF_SIGNED_JWT__VALIDATION_KEY（Duo Workflow 也有對應版本）。Security Affairs 明確指出後果：在閘道上執行命令會讓攻擊者進入一台持有 JWT 簽署素材、且位於 GitLab 執行個體與模型基礎設施之間路徑上的主機。

這就是玩具中的沙箱逃逸與正式環境中的沙箱逃逸之間的差別。逃逸不必觸及模型；它必須觸及持有模型呼叫簽署所用金鑰的處理程序。

GitLab 的產品文件（與該安全公告分別陳述）指出，建立或編輯自訂流程需要在管理專案中具備 Maintainer 或 Owner 角色，而執行自訂流程則需要 Developer 或以上角色。該公告並未確認這樣的對應關係，而 The Hacker News 指出，除了「Duo Agent Platform 存取權」之外，並未提及任何角色。讀者若要評估自身暴露風險，應將產品文件視為產品的權限模型，並將公告的沉默就當作沉默：沉默不等於矛盾。

已建立，以及未建立

該紀錄本身的欄位與上述一切相符，並未增添任何公告中沒有的內容。以下則是讀者無法從單行摘要中取得的分項。

• 確認：GitLab AI Gateway 中存在一個嚴重等級的漏洞，於 2026 年 10 月 2 日揭露，CVSS 9.9，CWE-1336，已驗證的 Duo Agent Platform 使用者可透過精心建構的流程組態觸及，導致在閘道主機上執行命令。

• 確立：受影響範圍——所有 AI Gateway 版本，從 18.1.6 起至 19.2.4 之前、19.3 起至 19.3.2 之前，以及 19.4 起至 19.4.1 之前——以及已修正版本 19.2.4、19.3.2 和 19.4.1。

• 已確認： GitLab 託管的閘道已在發布前完成修補，其客戶無需採取任何行動；自行託管的營運者已在發布文章前被直接聯繫，GitLab 在公告本身中說明了此事。

• 已確認： 將致謝歸於回報者 invisiblemeerkat，且未有任何在實際環境中遭利用的聲明。

• 尚未確定：是否有人利用了此漏洞。一份日期為2026年10月2日、可在NVD記錄中查見的CISA SSVC評估，將利用狀態列為「無」、可自動化列為「否」、技術影響列為「全面」；CISA已知遭利用漏洞目錄在其2026年10月20日的修訂版中並未列出CVE-2026-90970，這是我直接查核的。FIRST的EPSS模型於2026年10月21日將未來30天內遭利用的機率定為0.94%——偏低，但並非零。

• 尚未確認：存在多少自架閘道、其中有多少曾暴露於風險，或是否有任何閘道在修補前遭到攻擊。本紀錄中沒有任何來源提供數量，且 GitLab 的公告也未提供偵測方法。

受影響範圍，以及未列出修正的版本

版本算術並不像三個固定版本所暗示的那樣整齊。受影響範圍始於 18.1.6，而在低於 19.2.4 的任何版本分支上，都未發布任何修復版本。因此，從 18.1.6 到 19.1 系列之間的每個閘道都落在所述的受影響範圍內，卻沒有為其列出任何修補版本。The Hacker News 指出了同樣的後果以及隨之而來的問題：GitLab 的安裝文件要求管理員執行版本與其 GitLab 次要版本相符的閘道映像，而該公告並未說明 19.2.4 閘道能否搭配 GitLab 19.1 或更早版本運作，也未說明是否計畫為較舊的版本分支提供修正。正如 The Hacker News 所指出的，GitLab 的支援版本政策目前列出 19.4、19.3 和 19.2——正是獲得修復的那三個版本分支。

補救方式是更換容器，而非套用修補程式：閘道以獨立的 Docker 映像或 Helm Chart 形式提供。GitLab 的安裝指南說明需停止並移除執行中的容器、以 self-hosted-vX.Y.Z-ee 標籤提取新映像，並在環境變數維持不變的情況下重新啟動；Helm 部署則在 Chart 的映像欄位中設定標籤。無論是公告或安裝指南，都未提供任何簽章或指標，可據以區分遭攻擊的閘道與乾淨的閘道。

八個月前，同樣的錯誤類型

這不是 GitLab 第一次在 AI Gateway 中因範本注入漏洞而給出 9.9 分。2026 年 2 月 6 日，它發布了 AI Gateway 18.6.2、18.7.1 和 18.8.1，針對CVE-2026-1868，該公告將其描述為「不安全的範本展開問題」，其中 Duo Workflow Service 元件「有漏洞，可能透過精心設計的 Duo Agent Platform Flow 定義，對使用者提供的資料進行不安全的範本展開」，可用於在閘道上造成阻斷服務或程式碼執行。其 CVSS 向量與 10 月那次的完全相同，逐字不差，CWE 也是如此。通報者則不同：那次是由 GitLab 團隊成員 Joern Schneeweisz 在內部發現的。

十月安全公告沒有提到二月的那份，而 The Hacker News 明確指出了這一點。這兩者是否共享同一個根本原因、同一個未能奏效的修補，或僅僅是相同的語言與威脅模型，兩份公開文件都沒有回答。目前有記錄的是，AI 中介軟體元件中的一個模板引擎，如今已在同一年產生兩份評分相同的重大命令執行安全公告，而且第二份還需要外部研究人員才發現。

有什麼變化，以及還有哪些營運商有待決定

具體變更內容是三個映像標籤，以及一輪直接聯繫。GitLab 表示，他們在發布前已聯繫自助託管的閘道客戶，且安全公告與修正後的映像檔已於同一天一併發布。至於其他所有對象——GitLab.com、GitLab Dedicated，以及指向 GitLab 託管閘道的自架執行個體——修正程式早已在伺服器端套用，而且就 GitLab 的說法，無需採取任何行動。

對自架營運者而言，這個決定比一般修補週期更受限，也更令人不安。對於無法立即遷移的閘道，沒有任何變通辦法。目前沒有已發布的方法可判定主機先前是否遭入侵，這意味著唯一可事後採取的選項就是一般做法：把容器視為完整性未經證實的系統，並尋找其正常行為範圍之外的執行跡象。而對於執行 18.x 或 19.1 的閘道，公告完全未指明目標版本——這是 The Hacker News 報導、但 GitLab 通知未處理的疏漏。

檔案庫自身的分類刻意比供應商更窄。它將這筆條目記錄為漏洞，信心等級為 A，來源一致、沒有爭議、未記錄到實際損害，且嚴重性欄位為「高」，而 GitLab 與 NVD 則為「重大」。這些是對不同問題的回答：分數描述該缺陷可能容許什麼，而檔案庫的評級描述已知實際發生了什麼。在公開紀錄中，什麼都沒發生——沒有遭利用、沒有受害者、沒有事件報告。這筆條目的價值在於，它以 CVE 編號與已修復版本，確切記錄了一個提示範本如何在企業 AI 功能所依賴的中介軟體中變成命令列。