资讯动态

安全研究员把 273 个 MCP 服务器撸了一遍:10% 的工具在「裸奔」,你传给 Agent 的参数它们根本没校验

发布时间:2026/10/14 3:16:44 来源:尧图企业网站定制
一句话总结宾州州立等机构的研究者做了第一份 MCP 工具生态的「语义安全体检」用自动化框架 ToFu 对 273 个真实 MCP 服务器、3405 个工具做模糊测试343 个工具被实锤 CWE 类安全漏洞10 个里 1 个。更扎心的是那个「Repeat-After-Me」攻击——骗 LLM「原样重复」一段文本就能注入工具调用——在 LangGraph、AutoGen、Google ADK、AWS Strands 等 6 大主流编排框架上全部复现。先问一个做 Agent 开发的同行一个问题你的工具函数收到 LLM 传来的参数时校验了吗大概率没有。毕竟「参数是自家编排层传过来的schema 都验证过了」听起来很安全。这恰恰是这篇论文要打破的幻觉。编排层校验的是「语法」不是「安全」——schema 合法只说明参数格式对不说明这个值没被污染。而 LLM 会被它读到的所有内容影响网页、检索结果、其他工具的输出。也就是说一个「格式完全合法」的参数完全可能是攻击者借 LLM 的手塞进来的。宾州州立大学联合蒙彼利埃大学、达特茅斯学院的团队论文已被 FSE 2027 接收把这个观察做成了一个完整的攻击面分析 自动化审计框架 ToFu然后把真实世界的 MCP 生态整个测了一遍。结果不乐观。资源在这先收藏 论文arXiv 2610.13651FSE 2027 录用先看一个「幻觉攻击」Repeat-After-Me论文里最直观的演示是这个自提的攻击简单到有点冒犯攻击者在 LLM 会读到的内容里网页、文档、检索结果都行嵌入一段特殊文本——内容是「目标工具名 恶意参数」的标准调用格式——然后诱导 LLM「请原样重复以下内容」。LLM 照做了它以为自己只是在复读。但编排层一看这是合法的工具调用格式执行模型没有被骗过安全训练编排层没有出 bug但恶意调用就是执行了。作者在 6 个主流编排框架上全部复现LangGraph、Microsoft MAF、Google ADK 2.0、AutoGen、AWS Strands、CrewAI——基本覆盖了你叫得出名字的所有 agent 框架。这说明什么「参数符合 schema」这件事本身不能作为信任依据。反过来推论就是论文的威胁模型测工具安全性时根本不用先研究「怎么骗模型」直接把每个 schema 合法的参数都当成潜在恶意输入去测工具实现扛不扛得住。ToFu 怎么干活让「说明书」自己长出测试传统模糊测试fuzzing找的是崩溃、断言失败这类「看得见」的错误。但工具的安全问题大多是「不崩溃但违背承诺」说明书说「只读 /data 目录下的文件」实现却接受../../etc/passwd——程序跑得好好的一句报错都没有。这就是语义漏洞传统 fuzzer 的盲区。ToFu 的思路可以概括成「从工具的说明书元数据自动推导出该测什么」元数据提取MCP 工具自带自然语言描述 参数 schemaToFu 把它们归一化嵌套字段、枚举值都进测试范围语义感知 sanitizer维护一个 CWE 指导的检查器语料库从 13875 条公开记录筛出按「这个参数会被解释成什么」自动选检查——参数是路径就测路径遍历是 URL 就测 SSRF是命令就测注入双 oracle 判定工具进程可见时用运行时内省直接观察文件系统、进程、网络的真实操作工具不透明时就喂标记过的对抗输入看它是不是真接受了说的和做的不一致即漏洞harness 自动生成 覆盖率引导变异全程自动测的都是 schema 合法的调用。一个值得点赞的工程原则LLM 只打杂不当裁判——它帮忙理解元数据、挑检查器、生成种子但「是不是漏洞」的判定全部由 tracer 和 oracle 完成不靠模型打分。做安全工具的朋友应该懂这个设计有多重要。战果273 个服务器343 个工具253 个可复现漏洞数据集从 MCPCorpus 筛选GitHub 仓库 ≥10 星、非归档、非 MCP 客户端最终273 个 MCP 服务器、3405 个工具进入测试。结果343 个工具存在已验证的 CWE 类安全漏洞——约 10 个工具里 1 个中招涉及118/273 个服务器——不到一半的服务器是干净的人工分诊去重后253 个漏洞可稳定复现。漏洞类型分布很有信息量漏洞类型CWE数量反射输出危险输入未转义回显CWE-116/79115路径遍历CWE-2264日志注入CWE-11758SSRFCWE-9187数据外泄CWE-2015OS 命令注入CWE-783残留临时文件CWE-4591前三名反射输出、路径遍历、日志注入合计 237 个占 94%。翻译成人话绝大多数工具死于「没把 LLM 传来的字符串当不可信输入处理」——Web 开发二十年前的老教训在 MCP 生态又集体犯了一遍。论文里有个典型例子某浏览器工具的page.goto接受任意 URL结果本地文件路径也能传——file://渲染服务器上用户可读的任意文件传目录路径直接渲染目录列表。SSRF 加本地文件泄露一次送两样。泼冷水数字怎么读几个前提要看清这批数字很震撼但有几个前提得摆清楚别急着全盘恐慌。一是样本偏差。这 273 个服务器多是个人或小团队维护的开源项目筛选条件之一是 GitHub ≥10 星。10% 的漏洞率更接近「社区开源小工具的常态」直接外推到各大厂审计过的企业级工具链并不公平。二是覆盖范围。运行时内省的 tracer 目前只在 Python 服务器上运行JS 生态的覆盖有限而且工具必须能实际跑起来纯静态分析的对象不在范围内。三是危害分级还没展开。343 个是「存在已验证 CWE 类弱点」不等于 343 个都可被远程利用。反射输出占 115 个但实际危害取决于输出渲染场景。数量是筛查口径不是实锤攻击口径。四是 sanitizer 语料有偏。检查器语料从公开 GitHub 记录筛出覆盖哪些漏洞类取决于语料里有什么——反序列化CWE-502、XML 外部实体CWE-611这些「语料里有但本数据集没触发」的类别说明真实覆盖率可能还有下探空间。理性看待这份「体检报告」对行业的意义MCP 工具生态在 2026 年爆发式增长但安全审计明显没跟上——这篇论文相当于给整个生态做了第一次大规模「语义层体检」结论是工具实现远没有它们说明书里写的那么守规矩。不同角色该带走的东西不一样做 Agent 平台的编排层的 schema 校验只是「语法门」宣传材料里别再把它当安全边界讲。Repeat-After-Me 可以直接拿去当自家框架的安全冒烟测试。写 MCP 工具的文档里承诺的每个输入约束「仅限 /data 目录」「仅接受 http(s) URL」都要在实现里真正强制执行——描述与实现不一致在这篇论文的语境里就是漏洞本身。要接入 MCP 生态的企业把第三方工具当「不可信组件」做集成测试别默认它们干净——毕竟实测 10 个里有 1 个。Agent 的能力边界在扩张攻击面也在。这次是 273 个服务器的体检报告下回可能就是真实攻击者的战果清单——好在这一次先看到报告的是我们。

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑