为什么经典MCP服务器漏洞会威胁整个AI代理系统

关键要点

供应链爆炸半径广泛：Anthropic存在漏洞的SQLite MCP服务器在被归档前已被分叉超过5000次。这意味着未修补的代码现在存在于数千个下游代理中——其中许多可能已投入生产环境——在这些环境中，它默默地继承了SQL注入风险，任何攻击载荷都会在整个代理范围内传播。

SQLite MCP服务器漏洞可能影响数千个AI代理：传统的SQL注入为存储提示词注入开辟了新路径，使攻击者能够直接操纵AI代理，并显著提高攻击成功率。

SQL注入漏洞通过隐式工作流信任实现权限提升：AI代理通常信任内部数据（无论是来自数据库、日志条目还是缓存记录），代理通常将其视为安全数据。攻击者可以利用这种信任，在某个点嵌入提示词，随后让代理调用强大工具（电子邮件、数据库、云API）来窃取数据或横向移动，同时绕过早期的安全检查。

没有计划发布补丁，开发者必须自行实施修复：使用未修补分叉的组织面临重大的运营和声誉风险，包括潜在的数据暴露和服务中断。本文提供了推荐的修复清单以帮助缓解该漏洞。

漏洞详情

Trend™ Research发现了一个简单但危险的缺陷：Anthropic参考SQLite模型上下文协议（MCP）服务器实现中存在经典的SQL注入（SQLi）漏洞。尽管该GitHub仓库已于2025年5月29日归档，但在此之前已被分叉或复制超过5000次。需要注意的是，该代码明确标注为参考实现，不适用于生产环境。

存在漏洞的代码允许潜在攻击者运行未经授权的命令、注入恶意提示词、窃取数据并劫持AI代理工作流。在本博客中，我们研究了该缺陷的位置、其影响以及如何缓解。

漏洞位置

该漏洞位于源代码处理用户输入的方式中。它直接将未净化的用户输入连接到SQL语句中，然后由Python的sqlite3驱动程序执行——没有进行过滤或验证。核心的SQL注入漏洞（无参数化输入）如图1所示。

这个缺陷造成了严重的安全风险，特别是为SQL注入（SQLi）创造了完美条件，攻击者可以在系统中嵌入恶意查询。

OWASP的SQL注入预防备忘单十多年来一直保持相同的#1建议——使用参数化查询。这通过设计防止SQLi攻击，允许数据库区分代码和数据。忽视这一最佳实践重新开启了所有经典SQL攻击的可能性——身份验证绕过、数据泄露、篡改，甚至通过SQLite虚拟表技巧实现任意文件写入。

简单SQL注入如何劫持支持机器人

我们在此说明如何利用此漏洞。在我们的示例中，一个支持AI代理从SQLite MCP服务器提取工单。客户通过Web表单提交工单，而特权支持工程师（或机器人）对所有标记为"open"的工单进行分类。图2显示了当攻击者使用存在漏洞的SQLite MCP服务器将SQL注入载荷潜入支持AI代理时会发生什么。

以下是攻击展开的逐步分析：

攻击者提交工单

图3显示了当攻击者控制的body字段包含注入的SQL语句时的完整SQL查询。合法的支持工单请求将创建一个在第5行结束的SQL语句。然而，注入的内容（第5至11行高亮显示）用一个虚假的支持工单条目关闭第一个SQL语句，并创建一个包含恶意存储提示词的新条目。
恶意提示词通过存在漏洞的SQLite MCP服务器存储

这相当于LLM环境中的存储型XSS攻击，通常称为存储提示词注入，是LLM环境中众所周知的顶级风险。SQLite MCP服务器中的漏洞允许代理以"open"状态存储恶意提示词，有效绕过任何后端安全护栏，这些护栏本应对"待处理工单"进行提示词注入检查。
支持工程师或机器人使用AI代理对"open"工单进行分类

在分类过程中，支持工程师或机器人通过AI代理读取包含存储恶意提示词的工单，就像它是有效条目一样。
AI模型遵循提示词中的指令

存储的提示词引导LLM调用内部工具，如电子邮件客户端或其他MCP服务器，这些工具在特权上下文中可用且被允许。在我们的示例中，它将客户数据（customer.csv）发送到攻击者的邮箱（attacker@evil.com）。

由于电子邮件MCP工具以提升的权限运行，且分类工作流盲目信任任何标记为"open"的工单，单个注入的提示词结合存储提示词注入可以通过横向移动或数据泄露破坏系统。

在依赖MCP服务器存储和检索信息的AI代理环境中，看似微不足道的SQLi错误不再仅仅是数据层错误，而是变成了存储提示词注入的跳板，引导代理执行特权操作、自动化数据窃取和执行横向移动。

披露和当前状态

2025年6月11日，我们根据负责任披露准则私下向Anthropic报告了此问题。Anthropic回复称该仓库是归档的演示实现，因此该漏洞被视为"超出范围"。截至撰写时，根据GitHub问题#1348的讨论，没有计划发布补丁。此外，Anthropic的所有参考实现也已被归档。

快速修复清单

由于归档仓库没有计划发布官方补丁，保护其实现免受此漏洞影响的任务主要落在开发者和团队身上。我们在此列出了快速修复清单，用于在开发者自己的SQLite MCP服务器分叉或部署中识别和修补该漏洞：

手动修复存在漏洞的SQLite MCP服务器：通过将f-字符串替换为占位符。检查您是否在2025年5月29日前分叉了Anthropic的sqlite MCP服务器，或者是否使用了任何归档版本。如果找到，定位每个_execute_query调用并强制使用参数化执行，如下所示：

1
2
3
4
5
6
7
8


# 存在漏洞的代码
results = db._execute_query(arguments["query"])

# 快速修补
sql, params = arguments["query"], tuple(arguments.get("params", []))
if ";" in sql:           # 简单的单语句防护
   raise ValueError("stacked queries blocked")
results = db._execute_query(sql, params)  # 使用参数化输入

为SELECT … FROM {table}结构设置表名白名单
通过sqlite3配置禁止堆叠语句（isolation_level=None禁用隐式自动提交，但仍需要输入验证）
监控离开LLM边界的异常提示词（生成的SQL中出现意外的SELECT * FROM users，或分类代理突然爆发电子邮件）

结论和建议

这一事件以新的紧迫性强化了一个古老的教训——一旦经典输入净化错误位于AI代理之后，它们就不会局限于数据层。MCP服务器中的单个非参数化字符串可以通过数千个下游分叉级联，进入专有代码库，并最终在特权上下文中触发自动化工作流。当攻击者可以将教科书式的SQLi转化为存储提示词注入时，每个后续的LLM调用都可能被攻击者的指令控制——无论是读取客户记录、发送电子邮件还是渗透到相邻系统。

结论很明确。如果我们允许昨天的Web应用错误滑入今天的代理基础设施，我们就为攻击者提供了一条从SQL注入到完全代理妥协的轻松路径。要缩小这一差距，需要严格的编码标准、自动化的供应链监控和运行时护栏，这些护栏应假设任何存储的内容（无论其来源如何）都可能是恶意的。

除了快速修复清单外，以下是帮助预防此类漏洞的最佳实践：

重新审视OWASP的SQL注入预防备忘单：如前所述，OWASP长期推荐参数化查询作为防御SQLi的#1方法。这应该被视为基础实践，特别是在集成LLM或基于代理的系统时。
审计AI代理工作流中的隐藏信任假设：如果AI代理默认将内部数据视为安全数据，它可能容易受到存储提示词注入的攻击。审查AI何时以及如何读取、解释和操作用户生成或系统存储的输入。
限制特权上下文中的工具访问：AI代理不应无限制地访问电子邮件、文件系统或外部API等工具。引入验证步骤、批准或沙箱限制，以在发生利用时限制影响。
监控异常情况：密切关注可疑提示词、意外的SQL命令或不寻常的数据流——如由标准工作流之外的代理触发出站电子邮件。

经典MCP服务器漏洞如何威胁整个AI代理系统

本文深入分析了Anthropic SQLite MCP服务器中的SQL注入漏洞，该漏洞已被分叉5000多次，可导致存储提示词注入、数据泄露和代理工作流劫持，并提供了具体修复方案和最佳实践建议。