MCP（Model Context Protocol）是什麼？從 NadMesh 殭屍網路看 MCP 安全風險

「我們公司有在用 MCP 嗎？」

如果你是 IT 主管，這個問題的答案很可能是「有，但沒有人正式核准過」。MCP 的採用路徑通常是這樣：某位工程師想讓 AI 助理直接查資料庫，找到一個現成的 MCP Server，跑起來很好用，於是就留著了。它不在資產清單上，不在防火牆規則的討論範圍內，也不在弱點掃描的目標裡。

2026 年 7 月，奇安信 X 實驗室揭露的 NadMesh 殭屍網路，正好把這個盲區照亮了。這篇文章分成兩半：前半解釋 MCP 到底是什麼、為什麼企業會用它；後半用 NadMesh 這個實際案例說明風險長什麼樣，以及企業可以做什麼。

第一部分：MCP 是什麼

它想解決的問題

一個 AI 模型如果只能靠訓練時吃進去的資料回答問題，能做的事很有限。要讓它真的有用，就得讓它連到外面——查你的資料庫、讀你的文件、呼叫你的 API、操作你的工單系統。

問題是，這件事過去沒有標準做法。每一種模型、每一個 Agent 框架，都得為每一個外部系統各自寫一套整合。三個模型接五個系統，就是十五份要維護的黏合程式碼。而且換模型就得重寫一次。

MCP（Model Context Protocol）就是為了解掉這個 N×M 問題而生的開放協定，由 Anthropic 提出並開源，讓 AI 模型與外部工具、資料源之間有一套共通的溝通方式。系統只要實作一次 MCP，任何支援 MCP 的模型或代理都能接上。

基本角色

MCP 的架構概念上有三個角色：

• Host（主機）：使用者實際在互動的 AI 應用，例如聊天介面或代理程式
• Client（客戶端）：Host 內部負責與 MCP Server 對話的元件
• Server（伺服器）：把某個系統的能力包裝成標準介面對外提供，例如一台「資料庫 MCP Server」或「檔案系統 MCP Server」

MCP Server 通常會對外暴露幾類東西：工具（tools，可以被呼叫執行的動作）、資源（resources，可以被讀取的資料），以及提示範本（prompts）。

實際的呼叫走 JSON-RPC 格式——後面談 NadMesh 時會看到，攻擊者正是拿 MCP 的 JSON-RPC 工具呼叫來執行系統指令。

企業為什麼會想用它

用 MCP 的理由通常很務實：

• 不被單一模型綁死：換模型不用重寫整合
• 重複使用：一個內部系統包一次 MCP Server，所有 AI 應用共用
• 權限收斂：理論上可以在 MCP Server 這一層統一做授權與稽核

第三點是重點，但它同時也是問題的來源——當一個元件同時是所有 AI 應用的入口，它被攻破的後果就等比放大。

如果你正在評估要用哪個代理框架去串接這些工具，AI Agent 框架深度解析 有各框架在工具呼叫與狀態管理上的差異比較。

MCP 的風險模型跟一般 API 差在哪

很多人第一次接觸 MCP 會覺得「這不就是 API 嗎，我們已經有 API 安全的做法了」。差異在三個地方：

面向	傳統內部 API	MCP Server
呼叫者	你自己寫的程式，行為可預期	AI 模型，行為由自然語言驅動，不完全可預期
呼叫理由	程式碼裡寫死的邏輯	模型當下的判斷，可能受外部內容影響
權限範圍	通常按功能切分	常見的實作圖方便，直接給了寬鬆權限
資產可見度	在 API 閘道與資產清單上	工程師自行架設，常不在清單上
暴露面	多半在內網	為了方便，常直接綁在對外介面上

最後兩列就是 NadMesh 賴以維生的東西。

第二部分：NadMesh——把 AI 基礎設施當主戰場的殭屍網路

誰揭露的、什麼時候

中國資安業者奇安信 X 實驗室於 2026 年 7 月 17 日（週五）揭露，一個名為 NadMesh 的新型殭屍網路正在大規模掃描並入侵 AI 基礎設施與 MCP 服務。

該實驗室是在 2026 年 7 月初發現這套以 Go 語言打造的殭屍網路。命名來自它控制端原始程式碼自稱「n4d mesh controller」。

研究人員的判斷值得注意：它並非一次性的蠕蟲攻擊，而是一套仍在持續更新、具有商業營運思維的產品級惡意程式——具備管理介面、感染成效統計，以及分階段更新能力。

它怎麼找目標

NadMesh 的偵察方式有兩條線：

1. 內建逾 90 個雲端服務業者網段，作為自動掃描的基礎範圍
2. 利用 Shodan 搜尋曝露在網際網路上的 AI 工具，包括 ComfyUI、Ollama、n8n、Open WebUI、Langflow、Gradio，再把這些主機列為最高優先等級的掃描目標

這份名單基本上就是一份「AI 團隊常用工具清單」。它也提醒了一件事：這些工具很多是為了本地開發方便而設計的，預設往往沒有身分驗證。 一旦有人為了讓同事也能用而綁到對外 IP，就直接進了掃描器的視野。

它還會反覆掃描攻擊成功率較高的網段，並自動避開疑似蜜罐的主機。

它怎麼打進去

NadMesh 整合逾 20 種遠端程式碼執行（RCE）攻擊，攻擊手法涵蓋 MCP、Kubernetes、Docker、Redis、Elasticsearch、Jenkins 及 WebLogic 等服務。報導中舉出的具體例子包括：

• 透過 MCP 的 JSON-RPC 工具呼叫執行系統指令
• 在 Kubernetes 建立 Pod 並掛載主機目錄
• 利用未經驗證的 Docker 與 Redis 介面植入惡意程式

注意第一項的意義：這不是 MCP 協定被找到了什麼零日漏洞，而是一台沒有做身分驗證的 MCP Server，本來就對外提供「執行指令」這個工具。攻擊者只是照著協定規格呼叫它而已。

能執行指令的工具，配上沒有驗證的介面，等於一個公開的遠端 shell。

打進去之後要什麼

成功入侵後，NadMesh 會竊取：

• AWS 存取金鑰
• Kubernetes Service Account Token
• 環境變數
• Docker 設定
• SSH 連線資訊
• AI 模型存取權
• 可執行 SQL 或 Shell 指令的 MCP 工具資訊

奇安信的分析指出：攻擊者在意的並非受害主機本身，而是其中的雲端憑證、叢集權限及 AI 服務存取能力。

這句話對企業的意義很直接。AI 開發環境通常同時連接雲端平臺、容器、資料庫與外部工具，所以拿下一台開發機，等於拿到一整組通往其他系統的鑰匙。目前研究人員尚無法確定其最終的變現方式。

順帶一提，「AI 模型存取權」被列為竊取目標，代表你的 API Key 本身就是贓物。這一塊的治理實務可以參考 API Key 管理與安全完整指南。

為什麼難清除

NadMesh 會同時植入三種持久化機制：

1. SSH 公鑰後門
2. 惡意代理程式
3. Cron 監控程序

即使其中一項遭到移除，其餘機制仍可讓惡意程式恢復運作。

它還使用程式碼混淆、UPX 封裝與隨機填充，讓每個惡意程式樣本產生不同的雜湊值——這代表單靠雜湊值比對的偵測方式效果有限。

---

擔心自家 AI 開發環境有裸奔的服務？ 這類盤點通常一兩天就能看出輪廓，不用等到年度稽核。 預約資安評估，我們幫你檢視潛在風險。

---

企業該怎麼防

好消息是：NadMesh 的攻擊路徑幾乎全部是設定問題，不是難以修補的協定漏洞。這意味著大部分防禦動作你今天就能做。

一、先盤點：有沒有 AI 服務裸奔在網際網路上

這是投資報酬率最高的一步。從外部視角掃自己：

• ComfyUI（常見於 8188）、Ollama（11434）、Gradio、n8n、Open WebUI、Langflow 這類服務，有沒有任何一個可以從公網直接開啟？
• 內部有沒有人為了 demo 方便，把服務綁在 0.0.0.0 而不是 127.0.0.1？
• 雲端安全群組（Security Group）有沒有對這些連接埠開 0.0.0.0/0？

原則很簡單：AI 開發工具預設不該對公網開放。 需要遠端存取就走 VPN 或零信任閘道，不要直接暴露連接埠。

二、MCP Server 一定要有身分驗證與授權

這是 MCP 特有、也最容易被忽略的一點。因為 MCP Server 通常是工程師在本機起來的，很多實作預設就沒有驗證。

必做事項：

• 不要讓任何 MCP Server 在沒有身分驗證的狀況下對外服務
• 對 MCP Server 的呼叫要能識別是誰、透過哪個代理、呼叫了哪個工具
• 把 MCP Server 納入資產清單與弱點掃描範圍

三、對 MCP 工具套用最小權限

NadMesh 專門找「可執行 SQL 或 Shell 指令的 MCP 工具」。這給了一個很明確的設計原則：

• 避免提供通用的 execute_command / execute_sql 這類萬用工具，改成用途明確的具名工具（例如 get_order_status 而不是「隨便下 SQL」）
• 資料庫 MCP Server 預設只給唯讀權限，需要寫入再單獨開，並限定資料表
• 工具能做的事寫死在 Server 端，不要讓呼叫端決定範圍

一句話總結：不要把「一個可以執行任意指令的介面」包成工具，然後指望呼叫者是善意的。

四、憑證與金鑰治理

既然攻擊者的目標是憑證，那憑證的存放與生命週期就是主戰場：

• 不要把長效憑證放在環境變數或設定檔裡；改用短期憑證或雲端原生的身分機制（如 IAM Role、Workload Identity）
• AI 服務的 API Key 分環境、分用途，不要開發與正式共用一把
• 建立輪換與撤銷流程，並確認你有辦法在十分鐘內撤掉一把金鑰
• 對金鑰的使用量設異常告警——被偷走的 API Key 通常會出現用量突增

五、容器與叢集的基本功

NadMesh 用的 Kubernetes、Docker、Redis 攻擊路徑都是老問題：

• Docker API 絕不對外開放，也不要在沒有 TLS 與驗證的狀況下開啟 TCP 監聽
• Redis 一定要設密碼並綁定內網介面，關閉不需要的危險指令
• Kubernetes 限制 Pod 掛載主機目錄的能力（透過 Pod Security 標準或准入控制）
• Service Account Token 最小化：不需要呼叫 API Server 的 Pod 就不要自動掛載 Token

這些控制項多半已經寫在你的合規要求裡，只是 AI 開發環境常常被當成例外。相關的合規對照可參考 雲端運算資安指南：隱私安全問題與合規策略。

六、監控：找行為而不是找雜湊值

因為樣本雜湊值每個都不同，偵測重點要放在行為面：

• 出向連線異常：AI 開發機突然開始大量對外掃描，這是最強的訊號之一
• 憑證使用地點異常：AWS 金鑰從沒看過的地區或 IP 被使用
• 持久化機制變動：authorized_keys 被寫入、新增不明的 cron 工作
• MCP 工具呼叫紀錄：出現非預期的工具、非預期的頻率

七、把 AI 基礎設施納入既有流程

最後一點是流程層面的。多數企業已經有資產盤點、弱點掃描、變更管理、存取審查。真正的缺口通常不是「沒有能力」，而是AI 開發環境被當成實驗性質，沒有被納入這些流程。

把它納進去，多半就能解掉一半以上的風險。

一頁式檢查清單

立即可做（今天）

1. 從公網掃自己的 IP 範圍，確認沒有暴露的 AI 服務連接埠
2. 列出所有正在運行的 MCP Server，確認每一台都有身分驗證
3. 檢查 Docker API 與 Redis 是否對外開放

本月可做

1. 把 MCP Server 與 AI 開發主機納入資產清單與弱點掃描
2. 檢視 MCP 工具清單，移除或收斂萬用型的指令執行工具
3. 盤點 AI 開發環境中的長效憑證，改為短期憑證

本季可做

1. 為 AI 基礎設施建立變更管理與存取審查週期
2. 建立 MCP 工具呼叫的日誌與告警規則
3. 對 AI 開發環境做一次滲透測試，重點放在對外暴露面與憑證取得路徑

常見問題 FAQ

MCP 本身有安全漏洞嗎？

從 NadMesh 的案例看，攻擊者利用的是部署與設定問題，而不是協定本身被找到零日漏洞。具體來說，是透過 MCP 的 JSON-RPC 工具呼叫去執行系統指令——前提是那台 MCP Server 本來就對外提供了執行指令的工具，而且沒有身分驗證。所以防禦重點在「誰能呼叫」與「工具能做什麼」，而不是等協定改版。

我們只在內網用 MCP，是不是就安全了？

內網確實大幅降低風險，但不等於安全。第一，「內網」的邊界在雲端環境常比想像中模糊，一個設錯的安全群組就等於對外。第二，NadMesh 的目標之一是取得叢集權限，一旦攻擊者透過其他管道進了內網，沒有驗證的 MCP Server 就是現成的橫向移動跳板。內網部署應該視為縱深防禦的一層，不是唯一一層。

MCP Server 該給多大權限？有沒有簡單的判斷標準？

一個實用的問法是：「如果這個工具明天被陌生人呼叫一萬次，最糟會發生什麼事？」如果答案是「資料被刪光」或「可以執行任意指令」，那權限就給太大了。務實的作法是把萬用工具（任意 SQL、任意 shell）換成用途明確的具名工具，並且資料庫連線預設唯讀。

我們用的是雲端託管的 AI 服務，不自己架 MCP Server，需要擔心嗎？

自架的風險確實低很多，但要注意兩件事。第一，你的開發團隊可能已經在本機或測試環境架了 MCP Server 而你不知道——這正是需要盤點的原因。第二，NadMesh 的目標之一是 AI 模型存取權與雲端憑證，即使不自架 MCP，API Key 的保管、輪換與異常監控仍然要做。

偵測 NadMesh 這類威脅，靠防毒軟體夠嗎？

單靠雜湊值比對的偵測效果有限，因為 NadMesh 使用程式碼混淆、UPX 封裝與隨機填充，讓每個樣本的雜湊值都不同。比較有效的方向是行為偵測：出向大量掃描流量、authorized_keys 被異常寫入、新增不明 cron 工作、雲端憑證從陌生地區被使用。這些訊號在既有的 EDR 與雲端日誌中通常都撈得到，關鍵是有沒有把 AI 開發主機納入監控範圍。

已經有 ISO 27001 或其他合規認證，還需要為 MCP 另外做什麼嗎？

多數控制項其實已經涵蓋了——資產盤點、存取控制、金鑰管理、變更管理。缺口通常不在控制項本身，而在適用範圍：AI 開發環境常被當成實驗性質而排除在稽核範圍外。務實的作法是把 MCP Server 與 AI 開發主機明確列入資產清單與適用範圍宣告，讓既有的控制項自然生效。

---

需要 AI 基礎設施資安評估？

MCP 與 AI 開發工具帶進來的攻擊面，通常不在既有的弱點掃描與資產清單裡。與其等到憑證外流才發現，不如先做一次盤點。

CloudInsight 提供：

• AI 基礎設施暴露面盤點（MCP Server、AI 開發工具、開發主機）
• MCP 權限與工具設計檢視
• 雲端憑證與 API Key 治理建議
• 容器與 Kubernetes 安全組態健檢

預約資安評估，我們會在 24 小時內回覆。所有諮詢內容完全保密，沒有銷售壓力。

---

延伸閱讀

• AI Agent 框架深度解析：各框架的工具呼叫與架構差異
• API Key 管理與安全完整指南：金鑰儲存、權限與輪換實務
• 雲端運算資安指南：隱私安全問題與合規策略：合規框架與雲端風險對照

資料來源

• iThome：奇安信 X 實驗室揭露 NadMesh 殭屍網路大規模入侵 AI 基礎設施與 MCP 服務（2026 年 7 月）