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

关键要点

供应链影响范围广泛：Anthropic存在漏洞的SQLite MCP服务器在被归档前已被分叉超过5000次。这意味着未修补的代码现在存在于数千个下游代理中——其中许多可能已在生产环境中运行—— silently继承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所示。

图1. Anthropic SQLite MCP服务器源代码中导致SQL注入的代码行

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

OWASP的SQL注入防护备忘单十多年来一直将使用参数化查询作为首要建议。这从设计上防止SQLi攻击，允许数据库区分代码和数据。忽视这一最佳实践会重新打开所有经典SQL攻击的大门——身份验证绕过、数据窃取、篡改，甚至通过SQLite虚拟表技巧实现任意文件写入。

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

我们通过示例说明此漏洞如何被利用。在我们的示例中，支持AI代理从SQLite MCP服务器提取工单。客户通过Web表单提交工单，而特权支持工程师（或机器人）会处理所有标记为"打开"的工单。图2显示了当攻击者使用存在漏洞的SQLite MCP服务器向支持AI代理注入SQL注入载荷时发生的情况。

图2. 攻击示意图：显示SQL注入如何导致特权账户中的存储式提示注入和数据窃取

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

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

图3. 正常支持工单将在第5行结束。body由攻击者控制（第5至11行高亮文本）。漏洞允许添加额外的SQL语句

恶意提示通过存在漏洞的SQLite MCP服务器存储
这相当于LLM环境中的存储型XSS攻击，通常称为存储式提示注入，是LLM环境中众所周知的首要风险。SQLite MCP服务器中的漏洞允许代理以"打开"状态存储恶意提示，有效绕过任何后端安全防护措施（这些措施会对"待处理工单"进行提示注入检查）。
支持工程师或机器人使用AI代理处理"打开"工单
在处理过程中，支持工程师或机器人通过AI代理读取包含存储的恶意提示的工单，就像它是有效条目一样。
AI模型遵循提示中的指令
存储的提示引导LLM调用内部工具，如电子邮件客户端或其他MCP服务器，这些在特权上下文中可用且被允许。在我们的示例中，它将客户数据（customer.csv）发送到攻击者的邮箱（attacker@evil.com）。

由于电子邮件MCP工具以提升的权限运行，且处理工作流盲目信任任何标记为"打开"的工单，单个注入的提示结合存储式提示注入可通过横向移动或数据窃取危害系统。

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

披露和当前状态

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

快速修复清单

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

手动修复存在漏洞的SQLite MCP服务器，将f-strings替换为占位符：检查是否在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的首要措施。这应被视为基础实践，特别是在集成LLM或基于代理的系统时。
审计AI代理工作流中的隐藏信任假设：如果AI代理默认将内部数据视为安全数据，它可能容易受到存储式提示注入的攻击。审查AI何时以及如何读取、解释和操作用户生成或系统存储的输入。
在特权上下文中限制工具访问：AI代理不应无限制地访问电子邮件、文件系统或外部API等工具。引入验证步骤、批准或沙箱限制以在发生利用时限制影响。
监控异常情况：密切关注可疑提示、意外SQL命令或异常数据流——如代理在标准工作流之外触发的出站电子邮件。

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

本文详细分析了Anthropic SQLite MCP服务器中的SQL注入漏洞，该漏洞已被分叉5000多次，可导致存储式提示注入、数据窃取和代理工作流劫持，并提供了具体修复方案和安全建议。