所有使用 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）限制。
对于开发人员而言，这些操作看起来就像普通的工具调用。除非手动展开查看，否则几乎无法与之前的合法查询区分开来。
查询一旦执行完成，敏感数据会立即显示在该工单的对话中。
攻击者只需刷新页面，就能看到包含机密信息的新消息。
从权限角度来看，这一过程完全合规。
解决措施
这类攻击的根源在于两个设计缺陷的叠加：数据库权限过高（如 service_role），以及对用户提交内容的盲目信任。
以下是团队用以降低风险暴露的两项措施：
尽可能使用只读模式
启用该模式后，即使提示词被恶意利用，也无法执行插入（insert）、更新（update）或删除（delete）等操作。
添加提示注入（Prompt Injection）过滤器
这一机制可以通过在 MCP 外部构建一个轻量级过滤模块来实现，用于拦截传入数据，并对高风险输入进行标记或清除。
虽然该防护无法捕捉所有攻击，但它作为可扩展且切实可行的第一道防线，尤其适用于那些使用第三方 IDE（如 Cursor）且难以明确划分上下文边界的团队。
参考链接：https://www.generalanalysis.com/blog/supabase-mcp-blog
一键三连「点赞」「转发」「小心心」
欢迎在评论区留下你的想法！
— 完 —
专属 AI 产品从业者的实名社群，只聊 AI 产品最落地的真问题 扫码添加小助手，发送「姓名 + 公司 + 职位」申请入群～
进群后，你将直接获得：
� � 最新最专业的 AI 产品信息及分析 � �
� � 不定期发放的热门产品内测码 � �
� � 内部专属内容与专业讨论 � �
� � 点亮星标 � �
科技前沿进展每日见
第二证券-配资炒股技巧-怎么配资买股票-配资炒股开户提示：文章来自网络，不代表本站观点。
