一個未經身分驗證的 POST 至 Bifrost 的管理 API，以閘道使用者身分啟動了一個命令

2026年9月14日，JFrog Security Research 發布了CVE-2026-90898，這是一個命令執行漏洞，存在於Bifrost—由 Maxim 維護的開源 AI 閘道—並將其評為 10 分中的 9.8 分。此次攻擊只需一個 HTTP 請求。未經身分驗證的POST /api/mcp/client 會註冊一個 stdio MCP 用戶端，Bifrost 會將其解讀為程式名稱加上引數清單，並在任何 MCP 握手之前，立即以執行閘道的使用者身分啟動；在官方映像檔上，該使用者是 appuser。閘道也是操作員的供應商金鑰與虛擬金鑰所在之處，因此在那裡執行的程序可以取得憑證。讓此請求得以匿名的是隨附的預設值：governance.auth_config.is_enabled 為 false，而且，用 JFrog 的說法，「關閉驗證意味著每個呼叫者都是本機管理員。」沒有引用來源報導該漏洞曾遭利用。該記錄自身的來源、嚴重性等級與信心評估位於AI 事故檔案庫，與過去一年其他有記錄的 AI 閘道與 MCP 漏洞並列。

Bifrost 是一項單一服務，位於應用程式與其呼叫的語言模型之間。其儲存庫將其描述為一個以 Apache-2.0 授權的開源閘道，「透過單一與 OpenAI 相容的 API 統一存取 23 家以上的供應商……」，其功能包括 MCP 代理、虛擬金鑰、預算以及依供應商進行負載平衡，且在 2026 年 10 月 28 日約有 9,150 個 GitHub 星標。這樣的組合，正是為何在這個特定主機上取得 shell 值得一提臨界分數的原因：負責路由請求的處理程序，同時也是持有其路由至每個上游之憑證的處理程序。《Hacker News》在 9 月 22 日報導此一漏洞時直言其後果——由於閘道會儲存每個已連線供應商的 API 金鑰，因此在閘道處理程序上執行命令，便會讓攻擊者得以存取這些憑證。

整場攻擊只是一次 POST 請求

JFrog 的公告以參考編號 JFSA-2026-001686326 發布，描述了一個存在目的在於讓管理員新增 MCP 伺服器的端點。MCP 規格中的 stdio 用戶端並不是 URL；它是一個命令及其引數，主機程式預期會啟動它。Bifrost 透過管理 API 接受該組態，並在用戶端一經新增後就立刻啟動該程式。不需要先完成能力協商、伺服器身分檢查或握手——該公告明確指出，啟動程序並非由握手所觸發。

資安公告中的概念驗證是一個簡短的 JSON 主體，會傳送到身分驗證仍維持預設設定的閘道。它會註冊一個用戶端，該用戶端的命令是 /bin/sh，而其引數會寫入一個標記檔案，然後再讀回該標記。JFrog 補充了一個在事件應變期間很重要的操作細節：HTTP 要求可能會逾時，因為 Bifrost 正在等待一個永遠不會到來的握手；而日誌中出現逾時，並不代表命令未能啟動。屆時該程序早已在執行。

這筆 CVE 記錄由 JFrog 以 CVE 編號機構（CVE Numbering Authority）的身分指派，將該缺陷對應至 CWE-306（關鍵功能缺少身分驗證），以及 CWE-284（存取控制不當），並指出承載處理常式及其中介軟體的兩個檔案：transports/bifrost-http/handlers/mcp.go 與 transports/bifrost-http/handlers/middlewares.go。受影響的模組為 github.com/maximhq/bifrost/transports，平台為 Linux 與 macOS，涵蓋 2.1.0 以下的所有版本。

讓此請求保持匿名的預設設定

如果沒有第二個條件，這一切都不會被利用，而第二個條件正是產品本身的預設值。Bifrost 的管理驗證中介軟體受 governance.auth_config.is_enabled 控制，而該設定出廠為 false。關閉此設定後，中介軟體會將每個呼叫者視為本機管理員——此公告自身的摘要就指出，關閉驗證意味著每個呼叫者都是本機管理員——因此，原本會攔下該請求的檢查根本不在路徑上。

這項修正（pull request #6757）已於 2026 年 9 月 2 日合併到專案中，時間比該 CVE 發布早十二天，也比包含此修正的版本發布早六天。其描述對問題的樣貌異常坦率：這個 pull request 關閉的是同一個註冊 API 中的兩個未經驗證即可存取原語，而非一個。第一個是 stdio 用戶端。第二個是指向 loopback 或私人網路位址的 http 或 sse MCP 用戶端；該 pull request 稱之為針對內部服務的 SSRF 原語，「包括 169.254.169.254 雲端中繼資料端點」。現在，當請求在沒有真正憑證檢查的情況下到達處理常式時，兩者都會以 HTTP 403 遭到拒絕。已驗證的管理員仍保留這兩項能力，而操作人員仍可透過 config.json 佈建 stdio 用戶端。

那個第二個原語並沒有出現在 CVE 文字中。它出現在修補程式中，而這正是為什麼這項修正是一道閘門，而不是移除：這個功能從來不是缺陷。把未經身分驗證的呼叫者當成管理員才是。

管理 API 實際監聽的位置

可達性是漏洞記錄中來源描述得最一致、卻最少實際測量的部分。JFrog 的公告指出，原始二進位檔的預設值為 localhost:8080，這會使攻擊者僅能侷限於主機本身。同一團隊針對相關漏洞的公告則表示，官方 Docker 映像檔改為綁定 0.0.0.0，The Hacker News 也重述此點：若連接埠已發佈，該映像檔會使管理 API 可從容器外部觸及。Bifrost 自家 README 的快速入門執行「docker run -p 8080:8080 maximhq/bifrost」，而除非指定位址，Docker 的 -p 會將容器連接埠發佈到所有主機介面。GitHub 上該漏洞的公告記錄，回報的路徑已對已發佈的 maximhq/bifrost:latest 映像檔驗證，其中未經身分驗證的請求啟動了 /bin/sh，並以 appuser 身分寫入標記。

沒有任何來源提供的是一項數字。沒有對外開放於網際網路的 Bifrost 執行個體數量，沒有掃描結果，沒有遙測資料，也沒有受害者。紀錄中並未承載任何實際危害，而這項缺失是關於報導本身的事實，而非令人安心的保證——這類漏洞只有在兩個條件同時成立時才具危險性：一個暴露的監聽器，以及一個未經更動的預設值，而沒有人公布過它們同時出現的頻率。

一個端點，兩個缺陷，同一個根本原因

在 MCP 安全公告發布前八天，也就是 2026 年 9 月 6 日，同一研究團隊發表了CVE-2026-86242，這是通往同一處理程序的第二條未經身分驗證路徑。此漏洞由 Or Peles 發現，評分為 8.1，濫用了POST /api/plugins：Bifrost 會接受已啟用、且路徑為 HTTP URL 的自訂外掛，共享物件載入器會將以 http 為前綴的路徑視為下載，將內容寫入暫存的 .so 檔案，再把該檔案交給 Go 的 plugin.Open。若載入成功，可選的 Init 函式便會立即以閘道使用者身分、依攻擊者的設定執行。

建置類型決定攻擊者能得到什麼。在專案文件中針對自訂 Go 外掛所記載的動態連結建置版本上，載入預期會成功，資安公告稱之為未經驗證的遠端程式碼執行。在已發佈的靜態連結 Docker 映像檔上，plugin.Open 會失敗並顯示「Dynamic loading not supported」，因此同一個請求會降級為伺服器端請求偽造。可載入的外掛也必須符合主機的 Go 版本、作業系統、架構與連結方式，這是實質限制而非形式上的要求。修正版本為 transports/v2.0.0，透過拉取請求 #5763 提供，受影響範圍為其以下的所有版本。

陷阱在於發布順序。v2.0.0 修復了外掛路徑，卻沒有修復 MCP 路徑——《The Hacker News》明確這麼說，而 JFrog 的 MCP 公告也證實，v2.0.0 仍允許未經身分驗證的 stdio 註冊。一名在 9 月 6 日公告後迅速修補的操作人員，僅就這一點而言，直到 transports/v2.1.0 於 9 月 8 日發布前仍暴露於風險中。這兩個缺陷在兩份公告以及廠商自己的拉取請求中，都可歸結為同一句話：身分驗證停用是預設值。

資料來源確立了什麼，以及未能確立什麼

機制、版本範圍、修正方式與致謝內容，在安全公告、JFrog 所指派的 CVE 記錄、專案本身的提取請求與發行說明，以及 The Hacker News 之間都已達成一致。剩下的分歧在於嚴重程度，而這個分歧確實存在。

9.8 是 JFrog 作為指派 CNA 的分數，也是 NVD 所採用的分數。NVD 記錄將 reefs@jfrog.com 列為指標來源，且截至 2026 年 10 月 28 日，該條目仍顯示為「Awaiting Analysis」狀態，這表示 NVD 發布的是指派者的向量，而非其自身對該向量的分析。同一筆記錄所附、時間戳為 2026 年 9 月 14 日的 CISA 協調者 SSVC 評估顯示，利用狀態為「none」、可自動化為「yes」、技術影響為「total」。FIRST 的 EPSS 模型於 2026 年 10 月 27 日估計未來 30 天內遭利用的機率為 2.3%，在所有已評分 CVE 中位於第 83 百分位；而這項 CVE 與 CVE-2026-86242 均未出現在日期為 2026 年 10 月 27 日的 CISA 已知遭利用漏洞目錄中。

對此，Maxim 對該評級提出異議。該公司技術長暨共同創辦人 Akshay Deo 在給《The Hacker News》的聲明中表示，實際風險低於這個重大分數所暗示的程度，因為若要利用此漏洞，管理介面必須可從不受信任的網路存取，且操作人員必須未設定身分驗證；他說，預設且文件記載的部署方式會將閘道置於私人網路內。《The Hacker News》報導，Maxim 認為此缺陷屬於低嚴重性，並正與指派該 CVE 的 JFrog 合作修訂評估。該聲明只出現在那家媒體；未發現第二家出版物引用 Maxim 的立場，且截至 2026 年 10 月 28 日尚未發布任何修訂——CVE 紀錄最後更新於 9 月 14 日，NVD 條目則於 9 月 18 日更新，兩者仍為 9.8。

有兩處進一步的落差值得點名，而不是粉飾帶過。該專案在 GitHub 上的安全公告於 2026 年 9 月 23 日發布，並將 JFrog 的研究人員列為回報者，但這些公告仍將 MCP 漏洞評為 9.8、外掛漏洞評為 8.1，完全看不出 Maxim 所述的修訂版本。而且，那些公告中的受影響範圍是依據 Go 模組版本撰寫——低於 1.5.27 與低於 1.6.3——而非 JFrog 公告所用的 transports 發行標籤，因此營運人員在比對兩份文件時，必須先調和兩套編號方式，才能判斷某個建置是否受影響。

改變了什麼，以及營運商被告知要做什麼

時間順序從披露開始往回倒推，這是整份紀錄中最不直覺的部分。拉取請求 #6757 於 2026 年 9 月 2 日合併。transports/v2.1.0 是公告所指名第一個包含修正的版本，於 9 月 8 日發布——比 CVE-2026-90898 於 9 月 14 日發布早了六天。該專案的插件修正也以同樣方式早於其自身的公告：transports/v2.0.0 於 8 月 26 日推出，比 9 月 6 日的 CVE 早了十一天。追蹤版本發布而非情報來源的維運人員，在收到警告之前就已取得修補程式。

這次升級帶來的好處既有限又具體。在 2.1.0 及更新版本上，未經驗證的 stdio 註冊會傳回 403，且指令不會啟動；已驗證的管理員仍保留此能力，而 config.json 佈建仍可運作。對於任何無法升級的人，公告的權宜措施是將 governance.auth_config.is_enabled 設為 true、使用強式管理員認證，並讓管理監聽器遠離不受信任的網路。對於在停用驗證的情況下曾暴露運行的執行個體，JFrog 的指示不是去調查並抱持希望：而是將其視為已遭入侵，並輪換虛擬金鑰與供應商憑證。

版本算術是最容易被誤讀的部分。v2.0.0 並未修正此缺陷。1.6.x 系列直到 1.6.11 也不包含此修正，而該專案最新的 1.6 系列標籤是 transports/v1.6.11，於 2026 年 8 月 14 日發布；截至 2026 年 10 月 28 日，儲存庫中沒有 1.7 系列——因此該系列內沒有已修補的發行版，而 1.6.x 的操作者必須升級到 2.1.0 或更新版本，而不是等待回溯移植。目前發行線早已超過該點：transports/v2.3.2 於 2026 年 10 月 20 日發布。

發布後發生了兩件防禦方可以運用的事。該專案的 GitHub 安全公告——針對重大等級 MCP 漏洞的 GHSA-86gf-xh3g-rvxq，以及針對高風險外掛漏洞的 GHSA-2qp8-4xgm-fw6g——於 2026 年 9 月 23 日上線，讓相依性與公告資訊流多了第二個可供比對的識別碼。而 2026 年 10 月 13 日，一個針對 CVE-2026-90898 的偵測範本被合併進公開的 nuclei-templates 儲存庫，這意味著針對未經身分驗證的註冊嘗試所進行的檢查，現在可由掃描管線直接執行，而不必由每個團隊自行撰寫。

尚未定案的是嚴重性，而這將由仍在討論此事的兩個組織決定是否定案。據報導，Maxim 的立場是：9.8 高估了這個漏洞，因為它必須有暴露的監聽器，且預設值未設定，才會造成影響——這種說法原則上可檢驗，但尚未公開檢驗，因為沒有人公布有多少部署符合這兩項條件。JFrog 的立場則是其以 CNA 身分所指派的評分，該評分仍保留在 CVE 記錄與 NVD 中。在任一方公布修訂前，實務上的解讀都相同：這個漏洞確實存在，且已在公布的容器映像上完成端對端驗證；修補程式在警告發布前就已推出；1.6 系列完全沒有修補程式；任何在可達監聽器上以停用驗證方式運作的執行個體，都應視為憑證事件，而非排程修補。