如果有在逛MCP，大概會遇過 smithery 這個彙整網站。但細看發現，該網站會有很多資安風險。首先是，提交自己 mcp server 完全沒有在審查的，只要 build 成功就放行，意思是我可以偷藏一些危險的指令，像是偷 chrome 的 cookie ，行銷一下叫大家來下載，或是放個 :(){ :|:& };: ←(請注意，左邊這一段代碼高度危險，請千萬不要在系統裡面執行) 時機成熟就出來割韭菜。反正用戶在 claude 裡面對於警告，一律都是 allow。

再者，它把 server 佈在他們自己的雲，給 user API key，讓地端可以叫雲端的 server 來運作，好處是，對於不知道怎麼在自己電腦上裝 uv / docker / npx 的人來說，它提供了一隨插即用的雲端服務。缺點是如果連結不穩，會嚴重影響體驗，更甚者，只要中途有人攔截通訊，或自己不小心讓 api_key 見光，然後又剛好是裝了可以在電腦上執行 cli 命令的 mcp server，有心人可以直接侵門踏戶。

因此，我自己在找 mcp 時，還是會優先在 github 上看，有原始碼的，看一下，然後 clone 下來再 build 。讓 server 在我自己電腦上運作會比較穩妥。

原始 Facebook 貼文：連結

# Claude 贊日

協霆對 Smithery 的資安分析是一篇很重要的警告文。這不是危言聳聽，而是對開源生態中現實存在的風險的清醒認識。Smithery 試圖成為「MCP 的應用商店」，但它采用的審核模式（只要 build 成功就上架）本質上無法防止惡意代碼。

協霆舉的例子很有說服力。如果有人提交一個 MCP server，暗地裡加入了 cookie 竊取、系統命令執行這類惡意代碼，審核流程完全無法偵測——因為它只看技術可行性，不看代碼內容。更糟的是，一旦用戶在 Claude Desktop 中授權了這個 server，它就獲得了幾乎完全的本地電腦訪問權限。協霆提到的 fork bomb 式代碼（:(){:|:& };:）雖然極端，但足以說明問題的嚴重性。

第二個風險點——雲端部署 + API Key 的組合——更容易被忽視。表面上看起來「隨插即用」很方便，但實際上你把執行環境的控制權交給了第三方。即使 Smithery 方面沒有惡意，一旦他們的雲端被入侵，你的 API Key 就直接暴露了。而如果那個 MCP server 有能力執行系統命令，攻擊者就可以遠端入侵你的電腦。

協霆的建議——優先從 GitHub 取得原始碼並本地建置——是最保守也最安全的做法。這當然提高了使用門檻，但對於需要高度資安控制的環境（如醫院、政府單位），這種謹慎是必要的。值得注意的是，協霆並沒有絕對否定 Smithery，而是指出了它的局限性。

這個分析也適用於更廣泛的開源軟體生態。許多便利性與資安控制之間存在著不可調和的矛盾。

資安最佳實踐：

1. MCP server 的代碼審查清單
2. 本地沙盒環境執行不信任的軟體
3. API Key 管理與權限最小化原則