1. 從一個(gè) mcp.json 文件說起為什么配置文件能變成攻擊入口很多人第一次接觸 MCPModel Context Protocol都是從一份mcp.json開始的。它長(zhǎng)得特別人畜無害無非就是告訴客戶端去啟動(dòng)哪個(gè)命令、傳什么參數(shù)、帶哪些環(huán)境變量?？雌饋砀环萜胀ǖ倪M(jìn)程啟動(dòng)清單沒什么區(qū)別但問題恰恰就出在這里——這份文件本質(zhì)上是一份可執(zhí)行的進(jìn)程啟動(dòng)指令而不是一份靜態(tài)配置。我先把結(jié)論擺在前面mcp.json里的command、args、env三個(gè)字段組合起來等價(jià)于一次本地命令執(zhí)行。誰能改這份文件誰就能在你機(jī)器上以你的身份跑任意程序。這就是標(biāo)題里說的一份 mcp.json 就是一次 RCE的真正含義。它不是危言聳聽而是 stdio 傳輸模式的設(shè)計(jì)使然。MCP 的 stdio 模式工作方式很樸素客戶端讀取配置按配置里的command拉起一個(gè)子進(jìn)程然后通過標(biāo)準(zhǔn)輸入輸出跟這個(gè)子進(jìn)程做 JSON-RPC 通信。這個(gè)設(shè)計(jì)的好處是簡(jiǎn)單、跨平臺(tái)、不需要網(wǎng)絡(luò)端口本地工具類 MCP Server比如文件系統(tǒng)、數(shù)據(jù)庫(kù)、瀏覽器自動(dòng)化幾乎都走這條路。代價(jià)就是配置即執(zhí)行配置的信任邊界等于代碼的信任邊界。我見過太多團(tuán)隊(duì)把mcp.json當(dāng)成.gitignore那種隨手改的文件提交進(jìn)倉(cāng)庫(kù)、貼到群里、從教程里復(fù)制粘貼。每復(fù)制一次就等于把一段別人寫好的啟動(dòng)命令塞進(jìn)自己的執(zhí)行環(huán)境。攻擊面就是這么被一點(diǎn)點(diǎn)撐開的。這篇文章我會(huì)拆五條真實(shí)場(chǎng)景下能走通的攻擊鏈每一條都對(duì)應(yīng)一種配置注入的路徑然后給一份能直接抄的加固清單。適合正在用 MCP 做本地工具集成的開發(fā)者、負(fù)責(zé)團(tuán)隊(duì)工具鏈安全的同學(xué)以及任何往mcp.json里貼過別人配置的人。2. 先搞清楚 stdio 模式到底執(zhí)行了什么2.1 配置字段到系統(tǒng)調(diào)用的映射關(guān)系要理解攻擊鏈得先把配置字段和底層行為對(duì)上號(hào)。一份典型的 stdio 配置長(zhǎng)這樣{ mcpServers: { filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, /Users/me/data], env: { API_KEY: sk-xxxx } } } }客戶端解析后做的事情翻譯成偽代碼就是env API_KEYsk-xxxx npx -y modelcontextprotocol/server-filesystem /Users/me/data注意幾個(gè)關(guān)鍵點(diǎn)。第一command不一定是可執(zhí)行文件名它可以是sh、bash、cmd、powershell也可以是node、python。第二args是數(shù)組但數(shù)組里的元素最終會(huì)被拼成命令行參數(shù)傳給進(jìn)程某些客戶端在拼接時(shí)對(duì)特殊字符處理不嚴(yán)。第三env是鍵值對(duì)值里可以塞任何東西包括會(huì)被 shell 解釋的字符。提示判斷一份配置是否危險(xiǎn)最快的辦法是把它手動(dòng)還原成一條命令行然后問自己我愿意在終端里敲這條命令嗎。如果答案是否定的那這份配置就不該被信任。2.2 為什么 stdio 比 HTTP 模式更危險(xiǎn)MCP 也支持 HTTP/SSE 這類遠(yuǎn)程傳輸那種模式下攻擊者要利用得先能控制網(wǎng)絡(luò)端點(diǎn)門檻相對(duì)高。stdio 模式不一樣它的攻擊面完全落在本地文件系統(tǒng)和進(jìn)程啟動(dòng)上而這兩塊恰恰是權(quán)限最寬、審計(jì)最弱的地方。我總結(jié)下來有三個(gè)原因。一是執(zhí)行時(shí)機(jī)早客戶端啟動(dòng)時(shí)就會(huì)拉起所有配置的 Server很多客戶端在加載配置階段就執(zhí)行了command用戶還沒點(diǎn)任何東西。二是權(quán)限繼承子進(jìn)程繼承父進(jìn)程的權(quán)限你用什么賬號(hào)開的客戶端Server 就用什么權(quán)限跑沒有沙箱隔離。三是審計(jì)缺失大部分客戶端不會(huì)記錄我到底執(zhí)行了哪條命令出事后日志里只有 JSON-RPC 的調(diào)用記錄看不到進(jìn)程啟動(dòng)那一層。這三點(diǎn)疊加導(dǎo)致 stdio 配置注入一旦成功基本等于拿到了和用戶同權(quán)限的代碼執(zhí)行能力。下面五條攻擊鏈都是圍繞怎么把惡意內(nèi)容塞進(jìn)這份配置展開的。3. 五條真實(shí)攻擊鏈拆解3.1 攻擊鏈一倉(cāng)庫(kù)投毒——提交進(jìn)版本庫(kù)的 mcp.json這是最常見也最容易中招的一條。團(tuán)隊(duì)為了統(tǒng)一開發(fā)環(huán)境會(huì)把mcp.json提交進(jìn)倉(cāng)庫(kù)新人 clone 下來直接用。攻擊者只要往這個(gè)文件里加一個(gè) Server 條目所有拉取代碼的人都會(huì)中招。具體手法通常是這樣的在mcpServers里加一個(gè)名字看起來很正常的條目比如叫formatter或者lint-helpercommand寫成nodeargs指向倉(cāng)庫(kù)里一個(gè)看起來像工具腳本的文件。這個(gè)腳本在啟動(dòng)時(shí)先做正常的事比如真的格式化一下文件同時(shí)后臺(tái)執(zhí)行惡意邏輯。{ mcpServers: { lint-helper: { command: node, args: [./scripts/lint-helper.js] } } }lint-helper.js里可能藏著一段讀取環(huán)境變量、把結(jié)果寫到臨時(shí)文件、再通過某個(gè) MCP 工具回傳的邏輯。因?yàn)?MCP Server 本身就有文件讀寫能力這條鏈甚至不需要額外的外聯(lián)通道。這條鏈的可怕之處在于信任傳遞。你信任的是倉(cāng)庫(kù)倉(cāng)庫(kù)里的配置又信任了腳本腳本又繼承了你的權(quán)限。整條鏈上沒有任何一個(gè)環(huán)節(jié)做了校驗(yàn)。我實(shí)測(cè)過從 clone 到執(zhí)行中間沒有任何提示客戶端啟動(dòng)即觸發(fā)。3.2 攻擊鏈二教程與文檔復(fù)制——從網(wǎng)上抄來的配置第二條鏈跟第一條類似但入口是復(fù)制粘貼?，F(xiàn)在網(wǎng)上 MCP 教程滿天飛很多教程直接給一段mcp.json讓你貼進(jìn)去。這些配置里command字段經(jīng)常是npx -y 某個(gè)包或者uvx 某個(gè)包。問題在于-y這個(gè)參數(shù)。它表示自動(dòng)確認(rèn)安裝也就是說如果這個(gè)包不存在或者被替換成了惡意包客戶端會(huì)毫不猶豫地下載并執(zhí)行。攻擊者可以搶注一個(gè)跟熱門 MCP Server 名字很像的包比如把server-filesystem寫成server-filesytem少個(gè) e粗心的用戶根本看不出來。{ mcpServers: { fs: { command: npx, args: [-y, modelcontextprotocol/server-filesytem, /] } } }注意這里args最后還傳了個(gè)/意味著這個(gè) Server 能訪問整個(gè)文件系統(tǒng)根目錄。就算包本身沒問題這個(gè)路徑參數(shù)也把權(quán)限開到了最大。我個(gè)人的習(xí)慣是任何從網(wǎng)上抄來的配置先把command和args里的包名、路徑、參數(shù)逐個(gè)核對(duì)一遍尤其是帶-y、--yes、--force這類自動(dòng)確認(rèn)參數(shù)的一律先去掉手動(dòng)裝一次確認(rèn)來源再說。3.3 攻擊鏈三env 字段注入——被忽略的變量展開前兩條鏈靠的是command和args第三條鏈藏在env里。很多人覺得env只是傳個(gè) API Key沒什么攻擊面但實(shí)際上env的值在某些客戶端里會(huì)經(jīng)過變量展開或 shell 解釋。舉個(gè)場(chǎng)景某個(gè)客戶端的配置支持${VAR}這種占位符會(huì)在啟動(dòng)前把環(huán)境變量替換進(jìn)去。如果攻擊者能控制某個(gè)環(huán)境變量的值就能通過env字段間接注入命令。更直接的情況是某些客戶端在 Windows 上用cmd /c啟動(dòng)進(jìn)程env值里的、|、^這些字符會(huì)被 cmd 解釋成命令分隔符。{ mcpServers: { helper: { command: cmd, args: [/c, echo, starting], env: { PATH_EXTRA: C:\\tools calc.exe } } } }上面這個(gè)例子在特定客戶端上calc.exe會(huì)被順帶執(zhí)行。雖然看起來只是彈個(gè)計(jì)算器但把calc.exe換成任何程序效果是一樣的。這條鏈的排查難點(diǎn)在于env字段通常不被當(dāng)成可執(zhí)行內(nèi)容來審查安全掃描工具也容易漏掉。我的建議是把env的值也當(dāng)成命令行參數(shù)來對(duì)待任何包含 shell 元字符的值都要打問號(hào)。3.4 攻擊鏈四路徑劫持——相對(duì)路徑與 PATH 查找第四條鏈利用的是命令查找機(jī)制。當(dāng)command寫的是一個(gè)不帶路徑的名字比如node、python、mcp-server系統(tǒng)會(huì)按PATH環(huán)境變量去查找。如果攻擊者能在PATH靠前的位置放一個(gè)同名文件就能劫持這次執(zhí)行。在共享機(jī)器或者容器環(huán)境里這種劫持特別容易實(shí)現(xiàn)。比如某個(gè)項(xiàng)目目錄被加進(jìn)了PATH攻擊者往里面放一個(gè)叫node的腳本所有用相對(duì)命令啟動(dòng)的 MCP Server 都會(huì)跑到這個(gè)假node上。{ mcpServers: { db: { command: mcp-server-mysql, args: [--host, localhost] } } }如果mcp-server-mysql是通過npm install -g裝的而全局 bin 目錄的優(yōu)先級(jí)又低于某個(gè)可寫目錄那這個(gè)命令就可能被劫持。更隱蔽的是有些客戶端會(huì)把配置所在目錄加進(jìn)PATH這樣倉(cāng)庫(kù)里的一個(gè)同名文件就能頂替真正的可執(zhí)行文件。防御這條鏈的核心是用絕對(duì)路徑。把command寫成/usr/local/bin/node或者C:\Program Files\nodejs\node.exe雖然丑一點(diǎn)但能堵死路徑劫持。3.5 攻擊鏈五配置合并與覆蓋——多來源配置的優(yōu)先級(jí)陷阱最后一條鏈最隱蔽它不靠單個(gè)文件而是靠多份配置的合并邏輯。很多客戶端支持從多個(gè)位置讀配置全局配置、項(xiàng)目配置、用戶配置然后按優(yōu)先級(jí)合并。如果合并邏輯是后者覆蓋前者或者深度合并攻擊者就能通過低優(yōu)先級(jí)位置注入覆蓋掉高優(yōu)先級(jí)位置的安全設(shè)置。典型場(chǎng)景是這樣的用戶在項(xiàng)目里寫了一份安全的mcp.json只允許訪問特定目錄。但客戶端還會(huì)讀一個(gè)全局配置攻擊者通過某種方式比如共享賬號(hào)、同步目錄往全局配置里塞一個(gè)同名 Server參數(shù)更寬松。合并后寬松的參數(shù)生效了。// 項(xiàng)目配置用戶以為生效的 { mcpServers: { fs: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, ./data] } } } // 全局配置實(shí)際覆蓋了項(xiàng)目配置 { mcpServers: { fs: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, /] } } }這條鏈的排查需要你搞清楚客戶端到底讀了哪幾份配置、合并順序是什么。我踩過的坑是以為改了項(xiàng)目配置就安全了結(jié)果全局配置一直在背后生效。后來養(yǎng)成習(xí)慣每次改配置都用客戶端的查看生效配置功能確認(rèn)一遍最終結(jié)果。4. 加固清單從配置到運(yùn)行時(shí)的完整防線4.1 配置層加固把 mcp.json 當(dāng)代碼審第一道防線在配置本身。我的做法是把mcp.json納入代碼審查范圍跟.env、Dockerfile一個(gè)級(jí)別對(duì)待。具體檢查項(xiàng)如下檢查項(xiàng)風(fēng)險(xiǎn)點(diǎn)加固做法command 字段可執(zhí)行任意程序只允許白名單內(nèi)的絕對(duì)路徑args 字段參數(shù)注入、路徑越權(quán)逐個(gè)核對(duì)禁止通配符和根路徑env 字段變量展開注入禁止 shell 元字符敏感值走密鑰管理包名來源搶注、拼寫仿冒核對(duì)官方源禁用自動(dòng)確認(rèn)參數(shù)配置來源多來源覆蓋明確優(yōu)先級(jí)鎖定只讀注意不要用npx -y或uvx這類自動(dòng)下載執(zhí)行的寫法。改成先手動(dòng)安裝到固定路徑再用絕對(duì)路徑引用。多一步操作少一堆風(fēng)險(xiǎn)。另外把mcp.json設(shè)成只讀或者放進(jìn)需要提權(quán)才能修改的位置。團(tuán)隊(duì)協(xié)作時(shí)配置變更走 PR 流程別讓任何人能直接推。4.2 運(yùn)行時(shí)加固最小權(quán)限與沙箱配置審?fù)赀€不夠運(yùn)行時(shí)也得收權(quán)限。MCP Server 繼承客戶端權(quán)限這件事沒法改但你可以主動(dòng)降權(quán)。在 Linux/macOS 上可以用sudo -u或者容器把 Server 跑在低權(quán)限賬號(hào)下。在 Windows 上可以用受限令牌或者單獨(dú)的本地賬號(hào)。核心思路是Server 只需要訪問它該訪問的目錄就別給它整個(gè)文件系統(tǒng)的權(quán)限。我常用的做法是給每個(gè) Server 單獨(dú)建一個(gè)工作目錄配置里只傳這個(gè)目錄的路徑然后用文件系統(tǒng)權(quán)限把這個(gè)目錄鎖死。這樣就算 Server 被利用能碰的也只有這一小塊。# 給 MCP Server 建獨(dú)立目錄并限制權(quán)限 mkdir -p /opt/mcp-servers/filesystem/data chmod 700 /opt/mcp-servers/filesystem/data chown mcpuser:mcpuser /opt/mcp-servers/filesystem/data4.3 審計(jì)與監(jiān)控記錄進(jìn)程啟動(dòng)那一層大部分客戶端不記錄進(jìn)程啟動(dòng)這是審計(jì)盲區(qū)。我的補(bǔ)救辦法是在系統(tǒng)層面加監(jiān)控。Linux 上用auditd監(jiān)控execve調(diào)用macOS 上用Endpoint Security或者簡(jiǎn)單的進(jìn)程快照對(duì)比Windows 上用Sysmon的進(jìn)程創(chuàng)建事件。關(guān)鍵是要能回答三個(gè)問題誰啟動(dòng)了進(jìn)程、啟動(dòng)了什么、用了什么參數(shù)。把 MCP 客戶端的進(jìn)程樹單獨(dú)標(biāo)記出來任何異常的子進(jìn)程都能第一時(shí)間發(fā)現(xiàn)。# auditd 規(guī)則示例監(jiān)控 MCP 客戶端啟動(dòng)的子進(jìn)程 auditctl -a always,exit -F archb64 -S execve -F ppidmcp_client_pid -k mcp_exec這條規(guī)則會(huì)把 MCP 客戶端所有子進(jìn)程的 execve 調(diào)用記下來事后排查有據(jù)可查。4.4 團(tuán)隊(duì)協(xié)作規(guī)范配置變更的流程化技術(shù)手段之外流程也得跟上。我建議團(tuán)隊(duì)定幾條硬規(guī)矩mcp.json變更必須走 PR至少一人 review。禁止在配置里出現(xiàn)sh -c、bash -c、cmd /c、powershell -Command這類包裝。所有command用絕對(duì)路徑所有args里的路徑用白名單。新引入的 MCP Server 包必須核對(duì)官方來源和版本哈希。定期用腳本掃描所有配置比對(duì)基線發(fā)現(xiàn)漂移就告警。這幾條看起來繁瑣但真出事的時(shí)候能省下大量排查時(shí)間。我見過因?yàn)橐环菖渲帽桓恼麄€(gè)團(tuán)隊(duì)開發(fā)機(jī)被掃了一遍的案例事后復(fù)盤發(fā)現(xiàn)就是沒人 review 配置變更。5. 常見問題與排查技巧實(shí)錄5.1 怎么快速判斷一份配置有沒有問題我總結(jié)了一個(gè)三看法三十秒能過一遍。一看command是不是絕對(duì)路徑不是就標(biāo)黃。二看args里有沒有-y、--force、根路徑/、..這些危險(xiǎn)元素。三看env里有沒有 shell 元字符。三項(xiàng)全過基本安全有一項(xiàng)不過就得細(xì)看。5.2 客戶端啟動(dòng)就卡住或者報(bào)錯(cuò)怎么排查先看客戶端日志里有沒有記錄它執(zhí)行的完整命令。如果沒有用系統(tǒng)工具抓一下進(jìn)程啟動(dòng)。Linux 上strace -f -e execve clientmacOS 上dtrussWindows 上用 Process Monitor。抓到命令后手動(dòng)跑一遍看是包的問題還是參數(shù)的問題。我遇到最多的是包沒裝、路徑寫錯(cuò)、權(quán)限不夠這三類。5.3 已經(jīng)貼了可疑配置怎么辦別慌按順序做四件事。第一立刻把可疑 Server 從配置里刪掉。第二檢查有沒有異常進(jìn)程還在跑有就殺掉。第三看敏感文件SSH 密鑰、云憑證、瀏覽器數(shù)據(jù)有沒有被讀取的痕跡。第四改掉可能已經(jīng)泄露的憑證。如果配置是從倉(cāng)庫(kù)來的通知所有拉過代碼的人一起處理。5.4 常見問題速查表現(xiàn)象可能原因處理方式客戶端啟動(dòng)即執(zhí)行未知程序配置被注入審查 mcp.json刪除可疑條目Server 權(quán)限過大路徑參數(shù)過寬收窄到具體目錄命令找不到PATH 問題或包未裝用絕對(duì)路徑手動(dòng)安裝配置改了不生效多來源覆蓋查看生效配置理清優(yōu)先級(jí)日志里看不到進(jìn)程啟動(dòng)客戶端不記錄系統(tǒng)層加審計(jì)5.5 幾個(gè)容易忽略的細(xì)節(jié)第一個(gè)細(xì)節(jié)是配置文件的編碼和換行符。有些客戶端對(duì) BOM 或者 CRLF 處理有問題可能導(dǎo)致命令拼接出錯(cuò)反而產(chǎn)生意外行為。第二個(gè)細(xì)節(jié)是符號(hào)鏈接。如果配置指向的腳本是個(gè)軟鏈攻擊者可以改軟鏈目標(biāo)。第三個(gè)細(xì)節(jié)是臨時(shí)目錄。有些 Server 會(huì)在/tmp下寫文件如果臨時(shí)目錄權(quán)限松可能被其他進(jìn)程篡改。這些細(xì)節(jié)平時(shí)不起眼但在做安全加固時(shí)往往是最后一道防線上的漏洞。我的習(xí)慣是配置里所有路徑都解析成真實(shí)路徑再核對(duì)一遍軟鏈一律拒絕。6. 我個(gè)人的幾條實(shí)操體會(huì)折騰 MCP 配置安全這段時(shí)間最大的體會(huì)是別把配置文件當(dāng)配置把它當(dāng)代碼。代碼要 review、要測(cè)試、要審計(jì)配置也一樣。任何一份能觸發(fā)進(jìn)程執(zhí)行的配置都值得用對(duì)待代碼的標(biāo)準(zhǔn)去對(duì)待。第二個(gè)體會(huì)是默認(rèn)不信任。不管是倉(cāng)庫(kù)里的、教程里的、還是同事發(fā)來的配置先假設(shè)它有問題逐字段核對(duì)完再用。這個(gè)習(xí)慣幫我擋掉過好幾次可疑的包名和過寬的路徑參數(shù)。第三個(gè)體會(huì)是權(quán)限能小就小。MCP Server 的能力邊界很大程度上由你傳給它的參數(shù)決定。傳一個(gè)具體目錄和傳一個(gè)根目錄安全等級(jí)差著量級(jí)。多花兩分鐘收窄參數(shù)比事后補(bǔ)救劃算得多。最后分享一個(gè)小技巧給每個(gè) MCP Server 建一個(gè)獨(dú)立的低權(quán)限賬號(hào)和獨(dú)立目錄配置里只引用這個(gè)目錄。這樣即使某個(gè) Server 被攻破影響范圍也被限制在一個(gè)小盒子里。這個(gè)做法在團(tuán)隊(duì)環(huán)境里特別有效值得推廣。