我们总以为给AI装插件是"扩展能力"，但没人问过：这些插件本身会不会成为攻击入口？
一家叫Bawbel的安全团队做了件直接的事——他们写了款开源扫描器，把Smithery上最火的100个MCP服务器（模型上下文协议服务器，AI代理与外部工具通信的标准接口）全扫了一遍。结果：22个 flagged，28个安全问题，4个严重、24个高危。
五分之一。这是头部平台的真实数字。
「重要提示」成了攻击通道
最常见的漏洞叫「工具描述注入」（AVE-2026-00002），6个服务器中招。
原理荒唐又合理：MCP服务器的工具描述字段，本该解释"这个工具能做什么"，但开发者习惯写"IMPORTANT: Do not call this without authentication"（重要：未经认证请勿调用）。人类看是文档，AI代理看是指令——它真的会照做，或被诱导绕过。
扫描抓到的真实样本：
Context7写着「IMPORTANT: Do not...」；Google Sheets写着「WARNING: Do not...」；cultural-intelligence写着「IMPORTANT: Always...」；Senzing、Gantta、Brave Search都在描述里塞了「before calling/using this tool」的前置指令。
Bawbel团队的原话很克制：「有些可能只是过度热情的文档写法。」但问题就在这里——人机边界在AI代理眼里不存在。你以为在写注释，其实在写prompt。
Brave Search还被单独标记了一个越狱模式：描述里出现了「act as」。团队说这需要人工复核，不敢直接定性。
数据外泄的编码痕迹
第二类高频问题：工具输出外泄编码模式（AVE-2026-00026），4个服务器匹配。
YARA规则扫到了Jina AI、troystack、Name Whisper和一个未命名服务器，它们的响应里包含可用于走私数据的编码特征。但团队明确说：YARA很保守，只要出现「encode」就会匹配，四个全算真漏洞需要深挖。
这种模糊性本身就是现状——安全扫描能发现「看起来像攻击」的模式，但无法判断意图。工具可能在合法地做数据转换，也可能在偷偷外传。
文件类型撒谎与身份冒用
6个服务器被标记「内容类型不匹配」（AVE-2026-00024）。Bawbel的Magika引擎（基于机器学习的内容类型验证）发现，这些文件声称自己是.md（Markdown），实际是YAML，置信度82-90%。
名单包括：Google Sheets、Slack、Exa Websets、GitHub Code Search、ai-compliance-monitor、SIIL Ostomy Store。
一个技能文件披着Markdown的皮，里面是YAML的骨。不同解析器处理方式不同，现在可能无害，但边界案例迟早会炸。
PII提取：功能即漏洞？
3个服务器匹配「个人身份信息外泄模式」（AVE-2026-00013）。
Exa Websets的工具描述要求代理从页面提取「CEO name」；sbb-mcp匹配到「date of birth」；strale的描述涉及从URL提取数据。
团队的原话再次点破困境：「这些可能是合法工具在做合法的事，扫描器不懂意图，只懂模式。」
提取CEO姓名是商业调研还是隐私侵犯？取决于上下文，但AI代理没有上下文。功能描述本身成了攻击面。
最耐人寻味的发现
Bawbel团队特别提到Blockscout MCP Server——它的工具描述里出现了「exhaust the context」（耗尽上下文）。
这是资源耗尽攻击的经典前置步骤。是开发者不小心写了危险词，还是真有人在埋雷？原文没给结论，但这个问题本身比答案更重要。
为什么是现在
MCP（模型上下文协议）今年刚成为AI代理的事实标准。Anthropic开源后，Smithery这类注册表迅速聚集上千个服务器。每个服务器都是AI能调用的「手」——查邮件、改表格、搜网页、操作GitHub。
但安全模型还停留在「人类读文档」的时代。开发者按习惯写警告，AI按字面执行；扫描器按规则匹配，无法区分恶意与笨拙。
Bawbel的扫描是v1.0.1发布前的内部测试，团队没做任何宣传，先捅自己一刀。这种姿态本身说明问题：MCP生态的安全基线，目前靠自觉。
22%背后的结构性矛盾
数字需要拆解。28个发现里，有些是假阳性：YARA的保守匹配、文档与指令的模糊地带、合法功能被误读为恶意。但假阳性率高，恰恰说明攻击面定义不清。
真正危险的可能是没被扫到的——基于行为的漏洞、需要多步交互才能触发的逻辑缺陷、或者干脆是扫描规则还没覆盖的新手法。
Bawbel开源了工具，等于把问题抛给社区：谁来定义MCP的安全基线？Smithery作为最大注册表，有没有责任做准入检查？开发者写工具描述时，要不要开始像写代码一样考虑「被AI执行」的场景？
这些问题没有现成答案。但100个头部服务器里22个 flagged，至少说明「AI插件安全」不是边缘议题，而是正在发生的日常风险。
实用指向
如果你是MCP服务器开发者：把工具描述当成会被AI直接执行的代码来写，别写「IMPORTANT: Do not...」，写「此工具需要X参数」；用Bawbel扫一遍自己的发布包，假阳性好过真漏报。
如果你是AI产品使用者：问清楚你的代理调用了哪些第三方MCP，这些服务器有没有被任何安全流程覆盖——现在的默认答案很可能是「没有」。
如果你是安全从业者：MCP的漏洞分类（AVE-2026-XXXX）刚起步，规则库、行为基线、供应链审计全是空白。这是早期，也是定义游戏规则的时候。
热门跟贴