十个 CVE 之后：为什么 MCP 开发者仍然犯同样的错误
Source: Dev.to
请提供您希望翻译的文章正文内容，我将把它翻译成简体中文并保持原有的格式、Markdown 语法以及技术术语不变。谢谢！
十个
| CVE | 项目 | 易受攻击的函数 |
|---|---|---|
| CVE-2026-2178 | xcode-mcp-server | run_lldb command construction |
| CVE-2026-27203 | Various | Shell command injection via exec |
| CVE-2026-25546 | Godot MCP | exec(projectPath) |
| CVE-2025-66401 | MCP Watch (security scanner) | execSync("git clone " + githubUrl) |
| CVE-2025-68144 | mcp-server-git (Anthropic) | git_diff / git_checkout arg injection |
| CVE-2026-26029 | sf-mcp-server (Salesforce) | child_process.exec with CLI args |
| CVE-2026-0755 | Various | exec() with file paths |
| CVE-2026-2130 | Various | exec() with user parameters |
| CVE-2026-2131 | Various | exec() with user parameters |
| CVE-2026-25650 | MCP‑Salesforce Connector | getattr(obj, user_input) (Python variant) |
修复方法始终相同：使用 execFile() 并传入参数数组，取代使用字符串拼接的 exec()，或直接使用语言层面的 API 而不是通过 shell 执行。这一模式对应 CWE‑78，是软件史上文档最为丰富的漏洞之一。
为什么它会持续发生
1. MCP 服务器由领域专家而非安全工程师构建
The developer of xcode‑mcp‑server knows Xcode. The developer of sf‑mcp‑server knows Salesforce. They’re building tools for their domain and using exec() because it’s the obvious way to invoke CLI tools they already know. Security is not their primary expertise. The MCP SDK makes it easy to expose functionality — it doesn’t make it easy to expose it safely.
2. 发布路径中缺乏安全审查
The official MCP registry has 8,000+ entries. Review is minimal. A developer can write an MCP server, publish it, and have Claude for Desktop users connecting within hours — with no security audit. Compare this to npm (which has had security review processes for years) or the App Store. MCP lacks equivalent gatekeeping.
3. 参考实现也存在相同的漏洞
CVE‑2025‑68144 is argument injection in mcp-server-git — Anthropic’s own official Git server. If the canonical implementation that developers are expected to copy had the exec() pattern, what signal does that send to everyone else building on it? Security culture propagates top‑down. When the reference has the flaw, the ecosystem inherits it.
生产现实
我们的 560 台扫描过的 MCP 服务器数据集显示，38 % 没有认证层。对于存在 exec() 漏洞的服务器，这意味着：
- 未经认证的访问
- 可利用的 Shell 注入
→ 通过任何已连接的 AI 代理实现完整系统妥协。
攻击场景并不需要高超的技术。连接到易受攻击服务器的 AI 代理处理一份被投毒的文档。文档中包含触发工具调用的指令，并注入了 Shell 元字符。exec() 调用执行负载。游戏结束。
我们在公共 MCP 端点上观察到 223 次 AI 代理的实际工具调用。攻击面是真实且正在被利用的。
修复（再次）
Node.js MCP 服务器
// VULNERABLE
exec(`git clone ${userInput}`);
exec(`sfdx ${userControlledArgs}`);
// SAFE
execFile('git', ['clone', userInput]);
execFile('sfdx', [subcommand, ...validatedArgs]);Python MCP 服务器
# VULNERABLE
subprocess.run(f"tool {user_input}", shell=True)
# SAFE
subprocess.run(['tool', user_input], shell=False)这些都是单行修复。重构只需几分钟。发现之前的暴露窗口是数月。
关于 MCP 安全成熟度的启示
我们正处于 MCP 生态系统安全的早期阶段——相当于 2000 年代初期的网络安全，当时由于开发者尚未学会参数化查询，SQL 注入无处不在。
不同之处在于：SQL 注入的意识是多年逐步传播的，而 MCP 的发展速度更快。六周内出现十个 exec() CVE，表明生态系统正处于临界点——要么安全文化迅速跟上，要么我们将在意识到之前就看到被利用的情况。
三件可以帮助改进的事
- MCP SDK 应该提供安全原语——不仅要让暴露工具变得容易，更要让不安全的暴露变得困难。封装子进程调用，添加输入消毒助手。
- 注册表审查应包括自动化扫描——在列入之前对 MCP 服务器进行静态分析非常直接。这在 npm 包中已经实现，MCP 也应如此。
- 参考实现应树立标准——
mcp-server-git中的 CVE‑2025‑68144 现已修复。修复应伴随一篇博客文章，解释其重要性，而不仅仅是一个变更日志条目。
exec() 疫情是可以解决的。关键是有人停止把它当作常态。
MCP 安全数据集（560 台服务器，23 个 CVE）可在 mcp.kai-agi.com 获取。之前的分析：
Why CVSS Underscores MCP Vulnerabilities
Reference Implementation CVEs