MCPhantom 風險：AI 代理為何重裝已封存 MCP，98% 數字該怎麼讀？

MCPhantom 是 Glow Labs 對 AI 編程代理選到已停止維護 MCP 伺服器的命名。問題出現在工具接上電腦之前，因為選對功能，還不等於選到持續更新的實作。

當開發者只說要連 GitHub，代理可能從熟悉的範例挑出舊套件。它即使能順利完成安裝，仍需要有人確認這個程式由誰維護。

Glow Labs 在 2026 年 11 月 2 日至 3 日公布的調查中，98% 的分母是「已經裝了棄用伺服器」的觀察紀錄。其中多數未由使用者點名舊套件，不能讀成所有 AI 安裝都有98%出錯。

同批早期參考伺服器另發現四個高風險漏洞，但研究方表示尚未看到實際利用。累計下載數也只呈現取得套件的次數，無法換算成獨立受害者。

對已開放本機外部工具的團隊，這份研究值得轉成設定檔與核准清單的檢查。模型推薦可以提供候選名稱，維護狀態則要回到上游資料確認。

要決定清查範圍，先分清 MCP 協定、早期參考實作，以及服務商正式伺服器之間的關係。

MCP 工具怎麼接到電腦，舊套件為何仍會被選中？

MCPhantom 提醒團隊，代理選出的套件名稱仍要核對維護狀態。MCP 定義的是連接工具的方式，使用同一套協定的程式，維護者和更新頻率仍可能不同。

Glow Labs 將觀察到的舊套件選擇，解釋為模型沿用訓練時熟悉的名稱。這是研究方根據工作紀錄提出的解釋，沒有直接讀取模型內部狀態來證明因果。

MCP 是模型上下文協定的簡稱，用來讓 AI 代理透過統一介面呼叫外部資料庫、程式庫或瀏覽器。當 Anthropic 在 2024 年底首次推出這套標準時，為了示範怎麼串接服務，曾率先發布了 20 個官方參考伺服器。

隨著服務商開始提供自己的整合，早期參考實作可能退場。參考程式原本用來示範協定，服務商版本則由另一個團隊維護，名稱接近也不能把它們視為同一項產品。

既然各家服務商已經接手，Anthropic 便將其中 13 個早期參考伺服器陸續封存，並在儲存庫貼出公告，明確標示不再提供任何安全更新或錯誤修補。

封存公告能提供可核對的維護訊號，但代理若未查閱上游現況，仍可能沿用熟悉名稱。研究將這種選擇與訓練資料中的舊範例連結，沒有直接驗證模型的內部記憶。

依 Glow Labs 發布的 MCPhantom 調查報告，研究團隊在端點資產盤點時檢視了大量真實編程對話紀錄。

98% 的分母包含哪些紀錄？

研究先找出已設定棄用伺服器的工作階段，再檢視名稱由誰提出。在這些紀錄中，98% 不是使用者點名舊套件，另2%則是使用者直接指定名稱。

因此，這個比例回答的是舊套件選擇的來源，沒有提供所有代理安裝中棄用套件的占比。公開原文也未列出足以外推到全體開發者的完整抽樣資訊。

而且這個現象沒有侷限在單一廠商，研究方表示，樣本涵蓋 Claude Code、Cursor、Codex CLI、Claude Cowork 與 Claude 聊天介面等工具，都看到了相似模式。

觀察也涉及 Anthropic、OpenAI 與 xAI 的模型。但樣本中的共同現象，不能證明所有版本或相同工具的每次操作都會出錯。

套件登錄檔的棄用標示，和實際禁止安裝是兩回事。因為已棄用的套件雖然會從 npm 網頁搜尋結果中隱藏，導致代理上網搜尋時常找不到異狀，但只要代理直接下達 npx 指令，仍可能下載舊套件並顯示警告。

這也解釋了為什麼明明儲存庫已經封存，這批舊套件的實際使用量卻依然驚人。以下我把 Glow Labs 統計自 2025 年 7 月 10 日以來，Anthropic 已棄用參考伺服器的下載數據完整列出：

從上方表格可以看到，光是前四名套件就佔了超過 1,420 萬次下載，全部 12 款列入統計的封存套件合計高達 17,352,267 次下載。

這些下載數說明，封存不等於套件已停止流通。不過，重複安裝、自動化環境和同一人的多次下載都可能計入，因此不能把總數當成暴露電腦或受害者數量。

已封存的 Puppeteer 伺服器藏了什麼 RCE 漏洞？為何官方不修？

在這批被代理反覆安裝的舊套件中，威脅最高的是瀏覽器操作工具 server-puppeteer 裡面的遠端程式碼執行漏洞。在研究描述的工具呼叫與惡意參數條件下，外部內容可能誘導代理以該程序的權限執行非預期指令。實際影響範圍仍取決於帳號權限與隔離設定。

遠端程式碼執行簡稱 RCE，代表攻擊者可以跨越原本的功能限制，在目標電腦上直接啟動任意系統程序並執行命令。對於擁有原始碼讀寫權限與雲端金鑰的工程師電腦來說，這通常是最嚴重的資安風險等級。

Glow Labs 團隊在檢視這批早期封存的參考伺服器時，總共找出了 4 個高風險安全漏洞。其中 server-puppeteer 原本的用途，是讓 AI 代理能夠打開瀏覽器工作階段去讀取網頁或測試前端畫面。

但因為該套件對傳入參數缺乏嚴格邊界檢查，攻擊者只要結合提示詞注入，也就是在代理讀取的外部網頁內容中藏入惡意指令，就能誘導代理在呼叫瀏覽器工具時改為啟動作業系統上的任意執行檔。

在這條攻擊路徑裡，原本核准的瀏覽工具呼叫可能越過預期功能邊界。是否觸發仍取決於輸入、工具設定與授權條件，並非只要安裝就一定遭到攻擊。

為什麼代理內建的安全許可機制攔不住這次攻擊？

許多開發者會以為，現在的 AI 編程工具都有權限詢問視窗，應該會在執行危險指令前跳出警告。但實際上，這份研究展示了一種權限盲區：外殼核准了瀏覽工具，卻沒有辨識工具內部的危險參數。

當開發者同意讓代理使用 server-puppeteer 瀏覽網頁時，代理外殼就認定接下來的工具呼叫屬於合法的瀏覽器操作。

因為外殼看不出該套件內部存在參數漏洞，所以當攻擊者透過提示詞注入把瀏覽器啟動程序替換成系統命令時，這筆操作會直接順著已核准的瀏覽權限通過，在研究描述的授權路徑中沒有受到額外攔截。

漏洞通報時間軸與維護者拒絕修補的原因

發現這 4 個高風險漏洞後，Glow Labs 隨即展開負責任的漏洞揭露流程。在 2026 年 7 月 30 日，研究團隊先透過漏洞回報平台 HackerOne 提交報告，同時在 GitHub 建立安全通報。

同日 HackerOne 將該報告標示為超出處理範圍並結案，請研究人員改由 GitHub 管道聯繫。到了 2026 年 10 月 4 日至 11 日期間，Glow Labs 進一步將全部 4 個漏洞正式通報給負責核發漏洞編號的 Anthropic CNA 團隊。

然而在 2026 年 10 月，專案維護者正式回覆並關閉了這份安全通報。維護者說明，該伺服器早在 2025 年 5 月就已經歸檔封存，目前處於無人維護狀態，因此不會從這個儲存庫釋出修補版本，僅會評估在 npm 加上棄用警告字樣。

截至報告發布時，Glow Labs 表示尚未觀測到駭客在野外實際利用這 4 個漏洞發動攻擊。

不過研究團隊也提醒，隨著攻擊者開始利用新一代 AI 模型自動挖掘舊軟體漏洞，這類缺少維護安排、卻仍被代理選用的套件，會持續留下需要處理的風險。公開調查沒有量測實際攻擊機率的變化。

既然舊套件的維護者已經確認不會釋出任何修補程式，團隊自然會問，為什麼公司裡既有的資安掃描工具沒有在第一時間把這些套件擋下來？

為什麼代理設定檔可能落在既有資安盤點的盲區？

Glow Labs 描述的資安工具盲區，來自這類伺服器不一定被辨識為惡意軟體，也不會留在專案的標準依賴檔案裡。它們剛好落在端點偵測、原始碼掃描與資產盤點三種工具的交界縫隙中。

在一般軟體開發流程裡，團隊安裝套件會寫進專案根目錄的 package.json 或鎖定檔，所以安全工具只要掃描程式碼儲存庫就能找出問題。

但 AI 編程代理設定本地伺服器時，寫入的是代理專屬的本機設定檔，並且常透過 npx 在背景動態下載與啟動。

因此，僅檢查專案依賴清單，可能看不到代理設定的外部工具。是否能偵測仍要依各產品的資料來源與規則測試。以下我把四種常見企業資安防線面對 MCPhantom 時的監控標的與研究描述的可能缺口整理成對照表：

從表格可以看出，端點偵測工具看到的是開發者自己授權的合法程式在下載公開套件，不能只靠套件公開與否判斷這次選型是否安全。

而專門抓開源漏洞的軟體組成分析工具，一來找不到專案依賴紀錄，二來因為維護者以「已封存超出範圍」結案而沒有產生標準 CVE 漏洞編號，因此只比對此類依賴與漏洞編號的掃描，可能漏掉這一條路徑。

至於代理外殼本身，正如 Glow 共同創辦人暨研發副總裁 Ophir Arie 所形容，模型的記憶現在就像一個沒有棄用通知的套件管理員。

若外殼未另外整合套件狀態檢查，就不會知道該套件在 Model Context Protocol 官方參考伺服器儲存庫 是否已經移入歷史封存區，端點設定檔因而成為本次研究找到問題的重要資料來源。

看懂研究描述的盤點缺口後，工程與資安團隊就能針對代理寫入設定檔與執行安裝的環節，補上真正有效的攔截規則。

開發與資安團隊現在該怎麼清查與防範 MCPhantom？

要降低代理重新選到棄用套件的機會，最直接的做法就是停止讓 AI 代理自由決定套件名稱，改由團隊統一指定每項服務對應的官方伺服器。

因為這個風險並非外部駭客竄改套件造成，而是代理本身的選型決策過時，所以治理重點必須放在控制代理的選擇範圍。

第一步：全面清查本機設定檔並替換 @modelcontextprotocol 舊套件

資安與工程團隊今天就能用手邊既有的端點管理工具，搜尋所有開發者電腦上的 AI 代理設定檔。

無論團隊使用的是 Claude Code、Cursor 還是 Codex，若設定檔引用這批已標記棄用的早期參考伺服器，就應核對對應名稱與維護公告。不能只看到 @modelcontextprotocol 命名空間，就把仍維護的其他程式一併移除。

舉例來說，若發現設定檔裡還留著下載量超過 526 萬次的 server-github 或含有遠端程式碼執行風險的 server-puppeteer，就應安排停用與替換，並在測試環境確認服務商版本的權限、功能與部署方式。

替換後仍要追蹤新伺服器的維護與安全公告。由服務商提供是核對來源的起點，不能代替持續更新與權限驗收。

第二步：每項外部服務在公司內部只核准單一標準伺服器

如果團隊沒有明確規定連 GitHub 只能用哪一個套件，每位工程師下達提示詞時，不同模型又會各自從訓練資料裡挖出不同的舊套件名稱。

因此，企業應該為每項常用的外部服務選定唯一一個經過審核的標準伺服器，並寫進團隊共用的專案設定範本與代理指示檔中。

當標準設定已經隨專案版本控制一起發放給團隊成員，工程師就不必在對話框裡臨時要求代理幫我找一個工具接上去。這能限制模型臨時自選名稱的範圍，但核准清單本身也要有人更新，才能反映上游維護狀態。

第三步：將 npm 棄用狀態納入核准與阻擋策略

若代理外殼沒有另外檢查套件是否退役，團隊在審核任何新的外部工具前，必須把 npm 登錄檔上的棄用標記列為硬性檢查條件。

即使某個套件在網路教學文章裡出現頻率極高、累積下載量破百萬，只要上游儲存庫已經封存或標記棄用，就不應放行進入開發環境。

綜合來看，這份研究揭示的防禦做法，非常適合已經讓工程師在日常開發中使用 Claude Code、Cursor 或 Codex 串接資料庫與雲端服務的團隊立即採用。

相對地，如果你還把代理工具當成單純的聊天視窗、以為只要有跳出權限確認框就能擋住所有危險指令，就需要把套件來源與維護檢查納入原本的授權流程。

端點設定檔清查與套件核准清單，能讓團隊把選型依據從模型推薦，移回可追蹤的維護資訊。這不是消除所有供應鏈風險，但能針對本次觀察補上檢查。

MCPhantom 常見問題

MCPhantom 是駭客入侵 npm 植入惡意程式的供應鏈攻擊嗎？

不是。Glow Labs 明確指出，這次調查發現的案例並沒有外部惡意攻擊者竄改套件，觀察到的是代理自行挑選並安裝已封存停更的早期參考伺服器；與訓練資料舊名稱有關，是研究方對此現象提出的解釋。

為什麼只用 Claude Code 或改用 OpenAI 的 Codex 也會遇到 MCPhantom？

這份調查的現象跨越多種工具，但共同原因是研究方提出的解釋。研究方在上述工具與供應商的觀察樣本中找到相似模式，沒有公布可涵蓋每一個版本的全面失敗率。

server-puppeteer 的 RCE 漏洞未來會有官方更新補丁嗎？

依報告所載維護者回覆，該封存儲存庫不提供修補。維護者已於 2026 年 10 月正式關閉安全通報，說明該儲存庫自 2025 年 5 月起即歸檔封存且不再維護，因此不會釋出任何修補版本，開發者必須自行從設定檔移除該套件。

檢查專案裡的 package.json 能不能找出電腦上的 MCPhantom？

單看這份檔案可能不夠。因為編程代理通常是把伺服器寫在本機的代理設定檔中，再透過 npx 動態下載執行，未必會留在專案的 package.json 或鎖定檔，所以需要把代理設定檔與執行紀錄一起納入盤點。

把套件選型納入代理授權流程

已開放代理使用本機工具的團隊，可以先盤點實際設定，再把服務名稱對應到經審核的實作。這比只換一個模型更直接，因為研究揭露的是套件選擇與維護資訊之間的落差。

想持續追蹤 AI 開發工具、代理架構與工程實務限制，歡迎免費訂閱 AI 郵報。

延伸閱讀

延伸閱讀：Cloudflare security-audit skill 是什麼？六階段開源資安稽核與沙盒前提

延伸閱讀：cve.now 免費漏洞資訊站上線：AI 摘要、MCP 與依賴檢查該怎麼用？

原始資料來源

• Glow Labs：MCPhantom 研究報告原文
• GitHub：Model Context Protocol 官方參考伺服器儲存庫
• Glow Security 官方 X 公告貼文
• TrustMountAI 社群研究摘要貼文