MCP协议漏洞曝光：企业数据库或面临“裸奔”风险

所有采用MCP协议的企业请注意：您的数据库可能正暴露在巨大的安全风险之下！

最新研究表明，该协议存在重大漏洞，攻击者可利用LLM的指令/数据混淆漏洞直接访问数据库。

若用户提供的“数据”被精心伪装成指令，模型可能会将其误认为是真实指令并执行。

目前，MCP协议已成为智能体领域的行业标准，能够高效连接大语言模型与各类工具服务，众多企业纷纷采用。

然而，当模型处理网页、邮件、文档或图像等内容时，一旦这些隐藏了恶意指令的内容被模型误认为是真实指令执行，就可能触发未经授权的操作，例如泄露私人数据。

数据是如何被泄露的？

为了展示LLM的安全风险，研究者基于Supabase构建了一个典型的多租户客服SaaS系统。Supabase是一个开源的实时后端服务平台，具备数据库、身份认证、文件存储等功能。

该系统启用了标准的行级安全（RLS）机制，且未添加任何额外策略。

本次攻击演示所利用的一切要素均存在于默认配置中，包括标准service_role、默认模型、RLS和代表开发人员发起MCP调用的语言模型助手。

系统涉及的角色和权限边界如下：

支持代理无权访问任何非支持表或敏感表。要求支持代理提供任何敏感信息将导致拒绝。

让我们深入了解数据泄露过程。

攻击者首先提交了一份新的技术支持请求，其中包含精心构造的消息内容：既以友好提问作为伪装，又嵌入了直接发送给Cursor代理的明确指令。

在系统中的对话界面如下：

这条消息通过正常的工单提交通道进入数据库，存储在客户消息表中，未被任何过滤或阻断。

当支持代理查看工单时，他们只会按预期进行回复。需要注意的是，支持代理的权限不允许访问integration_tokens表，因此此阶段不会暴露任何敏感信息。

然而，当开发人员随后使用Cursor查看未处理工单时，就可能发生违规行为。他们可能会输入如下指令：

请显示最新的未处理支持工单。

此时，Cursor的代理通过Supabase MCP集成，自动发起一系列自动化SQL查询：

1. 加载项目的数据库架构
2. 列出所有支持工单
3. 筛选出状态为“未解决”的工单
4. 获取最新工单的所有消息

在此过程中，代理读取了攻击者提交的消息，并按照其中嵌入的指令执行相应操作。

最终，系统生成了两条新的SQL查询语句：

• 读取integration_tokens中的全部内容；
• 将读取到的结果作为新消息插入到当前工单的消息线程中。

这两条查询均由拥有高权限的service_role执行，该角色可以绕过所有行级安全（RLS）限制。

对于开发人员而言，这些操作看起来就像普通的工具调用。除非手动展开查看，否则几乎无法与之前的合法查询区分开来。

查询一旦执行完成，敏感数据会立即显示在该工单的对话中。

攻击者只需刷新页面，就能看到包含机密信息的新消息。

解决措施