安全與治理

Deadbugz：第四種 MCP 攻擊類別會潛伏到你信任它為止

作者：IdeaBosque最後更新：2026年9月29日

關鍵要點

74 分鐘內提交 23 個 pull request——2026 年 8 月 10 日，一個 GitHub 帳戶向互不相關的 AI、MCP 與開發者工具專案提交了行動所需的 PR。沒有任何一個透過 GitHub 的審查機制合併，但揭露時仍有 4 個處於開啟狀態（Pillar Security）。
三次正常呼叫之後，中繼資料被改寫——惡意 MCP 伺服器維護著一個按用戶端計數的呼叫計數器；在第三次 tools/call 請求之後，後續的 tools/list 與 prompts/get 回應會指示代理去搜尋 SSH 金鑰、AWS 憑證、shell 歷史和 Kubernetes 設定，並向使用者隱瞞該活動。
執行期間門控中繼資料投毒是第四種 MCP 攻擊類別——STDIO 命令注入 → 工具投毒 → SHA 固定繞過 → 信任建立後的執行期間門控中繼資料投毒。Deadbugz 的機制之所以在部署前最難偵測，是因為伺服器能通過初始檢查，而惡意載荷只會在用戶端建立起使用模式之後才啟動。
工具定義指紋是防禦手段——在核准時點擷取並比對工具定義指紋；對已核准伺服器的工具中繼資料出現的任何變化，一律視為安全事件，要求維運人員重新核准後，被更改的工具才能影響敏感操作。

一個 GitHub 帳戶在 74 分鐘內提交了 23 個 pull request，每個都提供一個能格式化文字、摘要文件的「productivity-suite」MCP 伺服器。該伺服器在最初三次工具呼叫中表現完全正常。到第四次，它改寫自身中繼資料，指示所連接的 AI 代理去搜尋 SSH 金鑰、AWS 憑證、shell 歷史和 Kubernetes 設定——並向維運人員隱瞞這一活動。2026 年 9 月 23 日，Pillar Security 揭露了該行動，並以埋在 4 個 pull request 中的投遞工件 deadbug-mcp.py 將其命名為 Deadbugz。雲端安全聯盟（Cloud Security Alliance）發布研究簡報指出，該攻擊在手法上接近此前攻擊 73 個 GitHub 儲存庫（含 Microsoft 的 azure/durabletask）的「Miasma」行動。

本文解析 Deadbugz 機制，將其歸位於四類 MCP 攻擊的分類體系，並指出堵住缺口的那項控制。它建立在 Plugin4Shell SHA 固定繞過分析與 MCP 安全強化檢查清單之上——兩者確立的控制恰恰被 Deadbugz 找到了缺口。

機制：按用戶端計數的呼叫計數器

Deadbugz 伺服器對外提供兩個工具——format_text 與 summarize——功能與名稱完全一致。伺服器在記憶體中為 tools/call 請求維護一個按用戶端區分的計數器。計數器從零開始，每次普通工具呼叫加一。當它到達三，後續的 tools/list 與 prompts/get 回應就變了：普通工具文件被替換為一些指令，引導所連接的 AI 代理去讀取敏感的本地檔案，並指示它向維運人員隱瞞這一活動。

這件事之所以重要，是因為 MCP 的工具定義不是標籤。用戶端把它們作為上下文提供給模型，幫助模型決定使用哪些工具、執行哪些操作。一個能在安裝之後更改這些定義的伺服器，可以在不改變工具無害名稱的情況下，改掉代理看到的指令。其公開源碼聲明瞭 tools.listChanged 此一能力——允許相容的用戶端重新整理工具中繼資料——因此伺服器根本不需要用戶端重連。它只需通知用戶端「工具列表已變更」，用戶端就會擷取新的、已被投毒的定義。

執行期間門控是一種規避研究的技術。簡短的檢查或有限的自動化測試只會拿到良性中繼資料。伺服器之所以能通過安全審查、沙箱測試與自動化掃描，是因為這些方法都不會在做了三次普通工具呼叫之後再去看伺服器接下來回傳什麼。Pillar 從公開來源確認了閾值邏輯與被更改的中繼資料，並透過純文字的良性請求觀測到該遠端服務在門控觸發後的中繼資料。

投遞路徑：看起來很常規的設定變更

該行動的投遞機制是向互不相關的儲存庫提交修改 MCP 設定的 GitHub pull request。在被審閱的 23 個 PR 中，17 個向專案的設定檔新增了遠端 MCP 端點（productivity-suite-mcp.onrender.com/mcp）；4 個設定 Python 去執行一個隱藏的本地檔案（~/.config/.cache/.sys/.deadbug-mcp.py）；2 個是目錄或清單提交。審閱時 23 個全部未透過 GitHub 的 PR 合併機制合併——19 個關閉、4 個開啟——但該投遞模式並不需要合併。它只需要一位維護者把設定變更拷貝進自己的環境，或者一位開發者看到 PR 後造訪連結的儲存庫並直接安裝該伺服器。

帳戶層面的投遞模式是有組織的：同一個公開帳戶（zellkernel）在 2026 年 8 月 10 日 21:52 UTC 至 23:07 UTC 之間提交的全部 23 個 PR 裡，使用了相同的產品名、相同的設定主題和相同的行動標記。該帳戶在收集時擁有 50 個公開儲存庫（其中 20 個為 fork），僅 8 月 10 日當天就建立了 21 個儲存庫。該 GitHub 主頁連結到一個 X 主頁（@llmgod），後者又回連至該 GitHub 帳戶——在投遞身份與 AI/LLM 相關公開活動之間存在一條公開的、可歸屬到帳戶的關聯。

這一投遞模式擴展了 Plugin4Shell 分析所記錄的供應鏈模式：把基於 PR 的設定變更當作完全繞過市集（marketplace）管制的載體。Plugin4Shell 利用與被固定提交同名的分支來攻破市集的 SHA 固定；Deadbugz 則乾脆不使用任何市集——它直接經由開源專案的貢獻工作流進入。

四種攻擊類別

MCP 安全家族現在有四種不同的攻擊類別，各自利用不同的信任邊界：

類別	機制	首次記錄	偵測難度
STDIO 命令注入	惡意命令嵌入 STDIO 設定字串	2026 年 4 月，20+ 個 CVE（Practical DevSecOps）	中等——靜態分析可捕獲 shell 元字元
工具投毒	良性工具的描述在核准後被更改為操縱代理	Invariant Labs，2025 年 4 月，WhatsApp 睡眠代理	中等——用戶端側的中繼資料變更偵測
SHA 固定繞過	以 SHA 命名的分支使市集的固定校驗失效	Plugin4Shell，2026 年 9 月	困難——需要在 checkout 之後斷言解析到的 HEAD
執行期間門控中繼資料投毒	惡意中繼資料被扣留到第 N 次呼叫，再經 `tools/list` 送達	Deadbugz，2026 年 9 月	最難——部署前測試不越過閾值

Deadbugz 的攻擊序列與四類分類體系，視覺化如下：

每一類攻擊都利用同一個結構性缺口：一個在錯誤的時間做檢查、或乾脆不做檢查的信任機制。STDIO 注入信任未經淨化的設定字串。工具投毒信任工具描述在核准之後不會改變。SHA 固定信任解析到的提交與被固定的名稱一致。執行期間門控投毒信任測試期間伺服器回傳的內容就是使用期間會回傳的內容。

Deadbugz 之所以部署前最難偵測，是因為伺服器在檢查期間的行為真的無害。惡意載荷並非以靜態分析能夠標記的方式藏在程式碼裡——它被門控在一個執行期間計數器之後，只有用戶端建立起使用模式之後才會啟動。一支連線伺服器、呼叫一兩次 format_text 再檢查回應的安全團隊，什麼問題都看不出。該攻擊的設計目標就是通過恰恰這種審查。

為什麼現有控制不夠

MCP 安全強化檢查清單把 12 項控制組織在傳輸、認證、工具註冊、執行期間與稽核五個層中。Deadbugz 利用的正是工具註冊層與執行期間層的缺口。該清單的工具註冊控制在核准時點驗證伺服器——在伺服器上線前檢查工具名稱、模式與描述。但 Deadbugz 的工具在核准時點確實無害。執行期間控制監視未授權動作，而被投毒的中繼資料本身並不是一個動作——它是一條指令，把代理引向一個隨後由代理執行的動作，而且表面上看仍在代理的授權範圍之內。

governed modules 論題——稽核日誌、速率限制、型別化錯誤與 kill-switch 架構使治理層成為安全邊界——多了一個攻擊類別作為證據。Deadbugz 機制從相反方向驗證了該論題：一個沒有治理控制（沒有中繼資料變更偵測、沒有工具定義指紋、沒有維運可見的「代理看到什麼」的差異）的伺服器，恰恰是該行動所利用的攻擊面。

防禦：工具定義指紋

Pillar 的建議具體且可實現：在核准時點擷取並比對工具定義指紋。當 MCP 用戶端核准一個伺服器時，它會記錄伺服器回傳的每一條工具定義的雜湊——名稱、描述、輸入模式與註解。當伺服器隨後通知用戶端其工具列表已變更（經 tools.listChanged）時，用戶端擷取新定義，與指紋比對，並把差異作為安全事件呈現給維運人員。在被重新核准之前，被更改的工具不能影響敏感操作。

這項控制之所以能堵住 Deadbugz 利用的缺口，是因為它不依賴部署前的測試。它監視的是伺服器在執行期間實際送達的中繼資料——在信任邊界已被跨越之後。無論執行期間門控何時觸發——三次、三十次還是三百次呼叫——指紋比對都能捕獲中繼資料改寫。該控制同樣能捕獲更早的工具投毒類別（Invariant Labs 的 WhatsApp 睡眠代理），因為兩類攻擊共享同一機制：核准後發生變化的工具描述。

對在生產環境執行 MCP 伺服器的團隊，有四個實施步驟：

在核准時點記錄工具定義指紋。 對初次連線時伺服器回傳的每條工具定義做雜湊。把這些指紋與該伺服器的核准記錄一起存入代理的設定管理系統。
監視 tools/list 與 prompts/get 回應中的漂移。 當伺服器通知用戶端工具列表已變更時，擷取新定義並與已存指紋比對。任何差異都標記為中繼資料漂移事件。
對被更改的工具定義要求維運重新核准。 在人類維運檢視差異並明確重新核准該伺服器之前，被更改的工具定義不能影響代理行為。這把一次無聲的中繼資料改寫變成一個可見的安全事件。
把敏感檔案讀取、憑證存取與程式碼執行關在策略之後——而不是工具中繼資料之後。 Deadbugz 載荷指示代理去搜尋 SSH 金鑰、AWS 憑證與 Kubernetes 設定。這些讀取應當是需要明確授權、由策略執行的操作，而不是遠端工具中繼資料所含指令的後果。Shadow AI 代理分析記錄了決定「中繼資料驅動的憑證搜尋是否會被察覺」的執行期間控制缺口。