MCP 协议到底出了什么问题
4 月 16 日，安全公司 OX Security 公开了一个让整个 AI 工具链都要抖一抖的发现：Anthropic 的 MCP（Model Context Protocol）协议存在架构级的远程代码执行（RCE）漏洞。不是某个版本的 bug，而是协议设计层面的问题——所有基于 MCP 官方 SDK 开发的工具天然就带这个风险。
MCP 是 Anthropic 推出的 AI agent 通信标准。你用 Cursor 写代码时连接的本地工具、Claude Code 调用的 shell 命令、VS Code 插件跑的 MCP server——底层都是这套协议。它已经被下载了 1.5 亿次，跑在 7000 多台公开可达的服务器上，实际受影响的实例可能超过 20 万台。
为什么你应该关注
这个漏洞的杀伤力在于它不需要破解任何防线。攻击路径大概是这样的：
1. 攻击者在一个看起来正常的文档/网页/代码库里埋一段 prompt injection 2. AI agent 读到这段内容后，按照指令调用 MCP tool 3. MCP 的 STDIO 传输层直接在宿主机上 fork 子进程执行命令 4. 攻击者拿到 shell access——API key、数据库凭证、SSH 密钥全部暴露
OX Security 在 Cursor、Claude Code、Windsurf、Gemini-CLI 上都跑通了这条链。LiteLLM、LangChain、IBM LangFlow 这些后端框架同样中招。
最讽刺的是 Anthropic 的回应——他们确认了漏洞存在，但说"STDIO 执行模型是安全默认值，清洗输入是开发者的责任"。技术上没毛病，但现实中做 MCP server 的人有几个会去做 input sanitization？AI agent 的输入来自模型输出，你没法穷举所有恶意 payload。
实操指南：现在就能做的 5 件事
如果你在用任何 MCP 相关工具，这几步今天就该做：
1. 把 MCP server 扔进 Docker 容器
最直接的防线。就算 agent 被 prompt injection 了，拿到的也只是容器里的 shell，不是你的开发机。
docker run --rm -it --network none \
-v /tmp/mcp-workspace:/workspace \
your-mcp-server--network none 很关键——断网防止数据外泄。
2. 用文件系统白名单限制 MCP tool 的访问范围
大部分 MCP server 实现都支持 allowedPaths 或类似配置。把它锁死在项目目录下，别让 agent 能读 ~/.ssh 或 ~/.aws。
3. 检查你的 MCP server 有没有在公网暴露
跑一下 ss -tlnp | grep ，看看是不是只绑定了 127.0.0.1。如果绑的是 0.0.0.0，你的 MCP server 对整个网络开放。
4. 升级到最新版 SDK 并关注安全公告
虽然 Anthropic 说不改协议设计，但各语言 SDK 后续可能会加沙箱层。TypeScript SDK 的 GitHub Issues 里已经有社区提的 sandbox PR。
5. 在 CI/CD 里加 MCP 安全扫描
OX Security 开源了检测工具，能扫描你的 MCP server 配置有没有高危暴露面。
常见问题
我只在本地用 Cursor，也有风险吗？
有。如果你打开了一个包含恶意 prompt injection 的代码仓库，Cursor 的 MCP agent 可能会在你的机器上执行命令。风险比远程服务器低，但不是零。
Anthropic 说"设计如此"，那这到底算不算漏洞？
看怎么定义。从协议规范来说，STDIO 传输确实就是"启动进程、读写 stdin/stdout"，没说要沙箱。但从安全角度看，一个让 AI 模型能在宿主机上执行任意命令的设计，在 2026 年被当成"安全默认值"，这个判断有问题。
公司项目用了 MCP，要不要停掉？
不用停，但要加防护。Docker 隔离 + 文件白名单 + 网络限制，三层做到位就行。比完全不用 AI agent 划算多了。
JR Academy 相关资源
这个漏洞的核心是安全意识和 DevOps 实践。如果你想系统学习：
- DevOps 课程 — 覆盖容器化、CI/CD 安全、基础设施即代码
- Cybersecurity 学习路线 — 从 OWASP Top 10 到供应链攻击防护
- AI 工具实战 Wiki — AI agent 开发最佳实践持续更新中
