Azure MCP Server 的 SSRF 可能將其受控識別權杖外洩至 URL

Microsoft 於 2026 年 3 月 10 日發布 CVE-2026-26118：這是一個伺服器端請求偽造漏洞，存在於 Azure MCP Server Tools，該套件可讓 AI 代理程式與 MCP 用戶端以自然語言對 Azure 資源執行動作。能與受 MCP 支援的代理程式互動的攻擊者，可提交惡意 URL 來取代正常的 Azure 資源識別碼；伺服器接著會向該位址送出對外請求，且用 Microsoft 的話來說，「可能包含其受控識別權杖」——把呼叫者原本不該看到的憑證交到其手中。Microsoft 將該漏洞評為 CVSS 8.8，並列為「重要」，而包含修正的套件為 1.0.2 與 2.0.0-beta.17。該公告記錄顯示在修補前並無遭到利用，亦無公開揭露，且未記錄到實際危害。這起事件是 Orca AI Incident Archive 中的一筆條目，該處保存完整紀錄，包含其引用來源、嚴重性等級與信心評估。

該公告實際上是怎麼說的

微軟安全回應中心（Microsoft Security Response Center）的記錄簡短扼要，而幾乎所有已公布的關於此漏洞的細節，都源自該記錄，或源自微軟對少數後續問題的回答。完整描述如下：「Azure MCP Server 中的伺服器端請求偽造（SSRF）允許經授權的攻擊者透過網路提升權限。」CVE 記錄於 2026 年 2 月 11 日保留該識別碼，並於 3 月 10 日 14:00 UTC 公開；微軟的發行說明與 NVD 的條目都記載了該日期。NVD 分析了該記錄，並於同日下午 18:18 UTC 發布。本文找到的唯一一則監管機構通知來自摩洛哥：DGSSI 的 maCERT 單位在 2026 年 3 月 11 日的公報中收錄了 CVE-2026-26118，將 Azure MCP Server Tools 列入受影響產品，並以其自身的「重要」（Important）風險等級標示，沒有另行評分，並回指微軟的發行說明。

此弱點對應到CWE-918，也就是伺服器端請求偽造（SSRF），而影響分類為權限提升。Microsoft 的基礎分數為 8.8，向量為 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H，時間分數為 7.7，向量為 E:U/RL:O/RC:C——其中 E:U 代表在設定分數時 Microsoft 並未掌握任何實際的攻擊程式碼，RL:O 則代表已有官方修正程式。NVD 採用相同的基礎分數，並將其評為 High；Microsoft 自家的三級量表則將其稱為 Important。

有兩個欄位與分數同樣重要。微軟的紀錄顯示已遭利用：否以及已公開揭露：否。CISA 針對 NVD 條目所做的 SSVC 決策紀錄，時間戳為 2026 年 3 月 5 日，在利用情況上看法一致——無——但判定技術影響為全面、可自動化為否。FIRST EPSS 模型在 2026 年 11 月 3 日抓取的資料中，估計未來 30 天內遭利用的機率約為 1.0%，位於第 62.8 百分位。這是一個已被發現並修復的漏洞，而非已知曾遭利用的漏洞。

資源識別碼如何變成對外請求

Azure MCP Server 是 Microsoft 對 Model Context Protocol 的實作，而 Model Context Protocol 是 AI 代理用來呼叫工具的介面。它的工具會接收代理所提供的參數——儲存體帳戶名稱、訂用帳戶識別碼、資料庫名稱——並將這些參數轉換為對 Azure 管理平面與資料平面發出的呼叫。Microsoft 的文件說明，此伺服器會透過 Entra ID 進行驗證，使用「您的 Azure 使用者認證或受控識別」，且存取權限受 Azure 角色型存取控制所限制。

這個缺陷存在於本應指定 Azure 資源的參數卻被接受為 URL 的地方。微軟自己的解釋：攻擊者「可透過向接受使用者提供參數的 Azure Model Context Protocol (MCP) Server 工具傳送特製輸入，來利用此問題。若攻擊者能與由 MCP 支援的代理程式互動，他們便可提交惡意 URL 來取代正常的 Azure 資源識別碼。」伺服器隨後會將請求傳送到被指示的位置，而非工具原本預定的位置。

把麻煩變成權限提升的關鍵，在於夾帶了什麼。Microsoft 表示，傳出要求「可能包含其受控識別權杖」，讓攻擊者得以「不必具備系統管理員權限」就擷取該權杖。受控識別權杖是一種持有人認證：持有者可在權杖到期前，向該識別獲授權存取的 Azure 服務出示它。同一段文字中用來緩解風險的另一半也同樣重要——攻擊者取得的是「與 MCP Server 受控識別相關聯的權限」，而且用 Microsoft 的話來說，「不會取得更廣泛的租用戶層級或系統管理員權限；只會取得與遭入侵受控識別繫結的權限。」影響範圍取決於有人授予該識別的權限，而實務上這往往超出單一工具所需。

Microsoft 並未指名受影響的工具或參數，本文所檢視的任何來源也沒有。這項省略本身就是一個細節：該公告描述的是一類工具——會接受使用者提供的參數，並可被誘導去抓取某個 URL——而非單一端點。

修正內容，以及承載它的套件

這不是 Windows 更新。Azure MCP Server Tools 以適用於 .NET 的 NuGet 套件、npm 套件，以及 PyPI 上的 Python 套件形式提供，而修正方式是在部署所用的那個套件中提升版本。微軟的公告列出受影響範圍為 1.0.0 到但不含 1.0.2，以及 2.0.0-beta.1 到但不含 2.0.0-beta.17，涵蓋 NuGet、npm 和 PyPI 發行版本。

npm registry 的日期顯示，修正後的建置版本在安全公告發布前就已存在於 registry 上。版本 1.0.2 的 @azure/mcp於 2026 年 3 月 6 日發布，比 CVE 公開早四天；2.0.0-beta.17 於 2026 年 2 月 6 日發布，比 Microsoft 保留 CVE 識別碼早五天，也比安全公告出現早一個月。無論 Microsoft 內部的先後順序為何，修補後的程式碼並不是為了回應公告發布日才撰寫的。NVD 與 GitHub 的安全公告資料庫對這些上限一致。它們在 PyPI 範圍的下限略有不同——NVD 說是 2.0.0-beta.1，GitHub 安全公告說是 2.0.0b14——這是兩份記錄自發布以來就一直存在的差異，且只影響 Python 部署需要回溯到多久以前。

該公告本身於 2026 年 3 月 20 日修訂，也就是發布後十天，並附註 Microsoft「已將產品新增至安全性更新表，這些產品記錄了用來交付 Azure MCP Server Tools 的各種封裝方式」。換句話說，公告第一版只列出了產品名稱，卻未列出其經由的所有通路；當補救措施是「升級套件」而非「安裝此 KB」時，這一點就很重要。

什麼尚未確立？

是誰發現的。Microsoft 的公告與 CVE.org 的記錄都未指明通報者；CVE 上的 credits 欄位是空的。這並不表示沒有人私下獲得致謝，只表示沒有公開的致謝。

任何利用情形。Microsoft 未記錄任何案例，CISA 的 SSVC 評估也認同，且本文所檢視的來源均未描述在實際環境中有身分遭入侵的情形。該記錄的 real-harm 欄位為 false，與此一致。低 EPSS 是預測，不是發現，而沒有通報事件並不證明未曾發生。

是否存在公開的漏洞利用程式。這正是二手報導出現分歧之處。Blueinfy 部落格於 2026 年 3 月的一篇文章稱，存在「公開的概念驗證漏洞利用程式，例如 GitHub 上的那些」，並警告「迅速武器化」，但未提供連結、酬載或逐步操作說明，也未示範該漏洞。微軟的記錄指出，該漏洞在修補程式發布前並未公開披露。2026 年 11 月 4 日以 CVE 識別碼搜尋 GitHub 儲存庫，只傳回一個儲存庫——2026 年 3 月 17 日發布的 Microsoft Sentinel 偵測實驗室，並非漏洞利用程式——而 Mallory 的漏洞頁面指出，兩個候選漏洞利用程式經篩選後遭否決。就現有證據而言，關於存在可用的公開漏洞利用程式碼的主張缺乏佐證；而沒有人嘗試過的主張同樣未經證明。

敘事框架。 PolicyLayer（一個供應商事件摘要網站）上的一篇文章，將 CVE-2026-26118 重新描述為一條未經身分驗證的遠端程式碼執行鏈，最終導致完整租用戶接管，並將此歸功於一位具名研究人員與 RSAC 2026 的示範。該頁面自身引用的來源標題卻是 SSRF，其日期與 CVE 時間線對不上，而且 Microsoft 的公告與 SecurityWeek 於 3 月 10 日的報導，都未描述程式碼執行。本文將 SSRF 與權杖的說法視為已確立的版本，不重複 RCE 的敘事框架。

為什麼是權杖，而不是請求，才是這項發現

伺服器端請求偽造是網頁軟體中最古老的漏洞類別之一，單獨來看，它通常是攻擊者用來觸及無法直接存取之系統的手段。這筆記錄之所以值得保留，在於附加在請求上的憑證。MCP 伺服器在設計上就是一個混淆代理：它持有身分，讓代理程式能代表使用者行事，而代理程式傳遞的每個參數，從伺服器的角度來看，都是受攻擊者影響的文字。當其中一個參數變成目的地而非名稱時，這個代理就會帶著自身的授權前往該目的地。

微軟的文件進一步闡明了這項風險集中的所在。文件將本機伺服器描述為「嚴格供組織內的開發人員使用」，同時另外發布了 Microsoft Foundry 與 Copilot Studio 中自架遠端伺服器的部署指南——在這些組態中，通常實際使用的認證是受控識別，而非開發人員自己的登入身分。該公告所述的權杖竊取路徑，具體針對的正是受控識別。它並未表示每一個安裝執行個體都曾曝險，也未說明有多少個曾曝險。

一般性的教訓，正是 OWASP 的 AI Security Verification Standard 現在用來教授此案例的那一課。AISVS 的協調編排章節將 CVE-2026-26118 列為其說明範例之一，並得出結論：「MCP 工具參數必須視為由攻擊者控制，且 MCP 伺服器的對外請求必須套用與任何其他代理驅動 I/O 相同的出口與來源政策。」這是一項控制建議，而非關於本次事件的調查發現，但對於應該改變什麼這個問題，這是目前任何人已發表過最具體的答案。

之後有什麼改變

有三件事，而且沒有一件是戲劇性的。微軟在三個生態系中都發布了修正套件，並修訂公告將它們列名其中。漏洞情報生態系則默默吸收了這件事：偏低的 EPSS 分數，以及一筆最後修改於 2026 年 6 月 17 日的 NVD 紀錄。而標準社群把它採納為教學案例，這是一種比修補程式更緩慢、卻更持久的回應形式。

對於仍在執行受影響版本的任何人，補救措施不變，也毫不光鮮：在部署所觸及的每一個套件管理員中，遷移到穩定線的 1.0.2 或更新版本，或預覽線的 2.0.0-beta.17 或更新版本。除此之外，該公告本身的邏輯暗示了三項控制措施——限制伺服器可對外觸及的範圍、只授予受控身分其工具實際需要的角色，並將任何可能變成 URL 的工具參數視為敵意輸入。這些措施都不是安然度過 CVE-2026-26118 的必要條件。每一項都會降低下一項對攻擊者的價值。

檔案館如何分類這一個

該紀錄被歸類為漏洞——是已發現的項目，而非已知曾被利用的項目——信心等級評為 A，表示有充分文件記錄且主要來源彼此一致，且未標記為有爭議。其真實危害欄位為 false，而其 AI 參與狀態為已確認，因為受影響的產品是 AI 代理與雲端控制平面之間的橋樑，而非恰好位於附近的通用服務。日期以日為精度記錄為 2026 年 3 月 10 日，且沒有結束日期，因為這是單一時間點而非一場行動。地區為全球，且地標旗標為 false。

有一個欄位的讀數與公佈的評分不同。該檔案庫的嚴重性依其自身量表記錄為 medium；Microsoft 與 NVD 都公佈的數字是 8.8，Microsoft 稱之為「Important」，NVD 則歸入「High」。該記錄的摘要以這個 8.8 開頭，而這項差異在於分級歸類方式不同，而非事實有所不同。

紀錄無法傳達的是，這個故事有多大一部分是空白。有一個漏洞，會把雲端身分交給任何以錯誤形式提出要求的人。有一個修正，在公告之前就已經發布。沒有被記名的發現者、沒有具名的工具、沒有已確認的利用行為，外界也無從得知是否有任何託管部署曾在持有強大身分的情況下執行過有漏洞的版本。該公告精確說明漏洞的作用，卻幾乎對其他一切保持沉默，而那份沉默正是最值得注意的地方。