SentryMCP：MCP服务器安全扫描工具，用Rust编写

我为 MCP 服务器构建了一个静态 + 运行时安全扫描工具（Rust）

**TL;DR：**MCP（Model Context Protocol）今年已披露了 40+ 个 CVE，当时没有针对它的专用扫描工具，于是我自己写了一个。sentrymcp 做静态分析（路径遍历、注入、工具投毒、缺失认证），外加一种运行时代理模式，可以捕获"地毯式抽身"（rug pulls）——即服务器在你的工具描述已获得批准后，悄悄将其描述内容改了。Rust 语言，MIT 协议，Docker 一行命令。仓库：https://github.com/zaydmulani09/sentrymcp

我一直都在做 MCP 工具链（反向代理、一些 agent 基础设施），某天我想找现成的东西来在上线前检查自己的服务器是否存在基本的安全问题。结果是真没有。

这让我很意外，因为 CVE 数量并不小。Endor Labs 分析了超过 2,600 个真实 MCP 实现，发现 82% 使用了易受路径遍历攻击的文件操作，67% 使用了与代码注入相关的 API，34% 使用了易受命令注入的 API。另外，研究人员估算未开启认证的服务器比例在 38-40% 左右——也就是说，野外每 5 个 MCP 服务器中就有近 2 个完全没有任何认证。

这些漏洞类型并非什么特殊罕见货色。Anthropic 自己的参考实现 mcp-server-git 就曾出现路径遍历漏洞，repo_path 参数从未针对配置的边界做过校验——正是那种在审计中反复出现的"开发者忘了一个检查"的标准模式。

所以：静态分析用来处理代码层面的问题，而由于 MCP 存在一种在源代码里根本不可能出现的攻击类别（服务器在会话中途改变工具描述，而用户早已批准了原始版本），所以还需要一个运行时模式来捕获它。

工具投毒检测是我最期待收到反馈的一项。MCP 的工具描述会被直接读入模型的上下文作为可信内容，因此攻击者如果控制了某条描述，就可以藏入指令，让 LLM 去执行，而用户看到的只是一个看起来无害的标签。sentrymcp 检查祈使句式的隐藏指令措辞、零宽/双向控制 Unicode 字符，以及同形字混用（混入西里尔字母或希腊字母外观相似字符的拉丁文本）。

mcpaudit scan ./some-mcp-server

输出按严重程度排序，附有 CWE 或 OWASP MCP Top 10 索引，并为每条发现提供一行修复建议，划分为三个区块——代码漏洞、工具投毒、认证/权限。

运行时代理模式，位于 MCP 客户端和真实服务器之间：

sentrymcp proxy -- <your-server-command>

它会在会话开始时对所有看到的工具定义建立基线，之后对每次 tools/list 响应做 diff。任何变化都会被标记并记为 JSON 事件，会话结束时输出人类可读的摘要。

Docker，无需本地安装 Rust 工具链：

docker build -t sentrymcp .
docker run --rm -v $(pwd):/scan sentrymcp scan /scan

Rust workspace，四个 crate：核心扫描引擎、规则 crate（从 TOML 文件加载检测模式，所以新增检查项无需重新编译）、CLI，以及代理模块。规则驱动设计是有意为之——路径遍历、注入和工具投毒的启发式检测全部是声明式的模式定义，包含严重程度、索引（CWE 或 OWASP MCP Top 10 id）和修复文本，使规则集容易在出现新攻击模式时扩展。

局限性（提前声明）

检测基于正则/模式匹配，而非 AST 或污染追踪。会漏掉那些通过中间变量传递后才到达 sink 的漏洞——这是已知且有文档记录的缺口，恰当的污染分析是自然的下一步。

工具投毒检查的描述提取是定向的，不是完整解析器——它处理 Python/TS/JS 中常见的注册模式，但并非穷举。

运行时代理的网络连接监控目前仅支持 Windows，而且是尽力而为（轮询 netstat，不是真正的沙箱）。

启发式发现（如"文件中任何位置都未发现可见的认证模式"）会附带一个独立于严重程度的置信度标记，因为 absence-of-pattern 检查本质上比 presence-based 检查噪声更大。

欢迎试用 / 期待反馈

仓库在此：https://github.com/zaydmulani09/sentrymcp — MIT 协议，欢迎贡献。如果你运行 MCP 服务器，我真心希望大家能用这个扫描器跑一跑自己的服务器，告诉我它漏掉了什么或者哪些是误报。测试用例集目前还很小，真实世界的反馈是让规则集真正有用而非仅在理论上正确最快的途径。