Azure MCP服務器曝9.1分漏洞：微軟把認證層整丟了

4月3日，微軟披露CVE-2026-32211，CVSS評分9.1。這不是某個邊緣組件的漏洞，是Azure MCP Server壓根沒做認證——任何能連上服務器的人，都能直接拉取你的工作項、代碼倉庫、流水線配置，甚至API密鑰。

一個"可選"設計釀成的災難

MCP（Model Context Protocol，模型上下文協議）是Anthropic去年推出的開放標準，讓AI Agent能調用外部工具。簡單說，它給大模型裝了"手"，可以操作GitHub、查數據庫、跑流水線。

但MCP規范把認證標為"可選"。官方文檔白紙黑字寫著："MCP SDK不包含內置認證機制。"這個設計把安全責任甩給每個具體實現。Azure MCP Server選擇了最簡單的實現方式：跳過。

結果是一臺處理企業級開發基礎設施的服務器，門戶大開。攻擊者無需有效憑證，就能訪問配置詳情、認證令牌、項目數據。這不是代碼寫錯了，是架構圖上直接缺了一塊。

諷刺的是，這個漏洞被發現前，安全社區已經盯上@azure-devops/mcp。3月31日起，監測機構開始掃描這個包，提前標記了兩處風險：

第一，安裝腳本篡改npm配置。包的preinstall腳本會執行npm config set registry https://registry.npmjs.org/，覆蓋機器上的自定義倉庫配置。這本身不算惡意，但修改npm配置的安裝腳本，是已知的供應鏈攻擊向量——就在同一周，axios包剛出過類似問題。

第二，發布鏈條不可追溯。包由個人npm賬號antonatms發布，而非GitHub Actions可信發布流程，沒有來源證明（provenance attestations）將發布產物與驗證過的構建關聯起來。

監測機構給出的 verdict API 評分：75/100，風險等級"中等"。然后CVE來了，認證缺失的問題讓風險評級顯得保守。

為什么偏偏是MCP？

MCP的架構天生適合"能力聚合"。一個Agent可以串接多個MCP服務器：查Jira、讀Slack、部署到AWS。每個連接都是一次權限讓渡。

傳統API集成，你至少知道自己在調什么、權限邊界在哪。MCP把這一切封裝成"工具"，Agent自動選擇、自動調用。用戶看到的是自然語言交互，底層是一連串權限跳轉。

這種抽象帶來便利，也模糊了安全感知。當Azure MCP Server缺失認證層時，問題被進一步放大：不僅是"Agent能做什么"，而是"任何人能冒充Agent做什么"。

OWASP的MCP Top 10草案把"認證與授權不足"（MCP07）列為核心風險，正是針對這種場景。很多MCP服務器直接以宿主環境權限運行，沒有獨立鑒權。一旦網絡邊界被突破，就是全盤暴露。

微軟目前的緩解方案是防火墻隔離：限制MCP服務器端點的網絡訪問。補丁仍在開發中。

生產環境該問什么

對部署MCP服務器的團隊，安全檢查清單需要更新。舊問題："這個包有沒有惡意代碼？"新問題："這個服務器有沒有實現該有的安全控制？"

具體動作：

- 盤點所有MCP服務器實例，確認網絡隔離策略

- 檢查npm包的發布來源，優先選擇有來源證明（provenance）的包

- 審查安裝腳本行為，警惕修改系統配置的preinstall/postinstall

- 對MCP服務器實施獨立認證層，不依賴"可選"規范

AgentScore這類監測服務目前覆蓋60+ MCP包，持續跟蹤供應鏈風險。但工具只能輔助判斷，最終的安全架構決策仍落在實施團隊。

CVE-2026-32211的特殊之處在于，它暴露了一個系統性盲區：當協議把認證標為"可選"，多少實現者會選擇"省略"？微軟不是唯一踩坑的，只是名氣最大、評分最高。

Agent生態正在快速膨脹。每個新協議、每個新服務器，都是潛在的權限放大器。安全團隊的習慣性假設——"大廠出品，認證總該有吧"——在這個案例里被證偽。

你的Agent pipeline里，有多少個MCP服務器正在裸奔？