𝐂𝐮𝐫𝐬𝐨𝐫 𝐌𝐂𝐏 攻击现象：一句话，就能让你的私有数据库裸奔 ---"一句话劫持"：
prompt注入如何撬开数据库后门
1）危险比你想的更近 在我们最新的实测里，攻击者只用在客服工单里插入一段"看似友好、实则暗藏指令"的留言，就让 Cursor 的 MCP 代理自动把 integration_tokens 私密表整段复制出来，展示在公开工单页面。 整件事耗时不到 30 秒：没有越权、没有报警，开发者甚至以为自己在"正常检索工单"。结果？Slack、GitHub、Gmail 等 OAuth access token / refresh token 全部泄露，连过期时间都一清二楚。
2）一次完整泄露的五步解剖
-环境：新建 Supabase 项目，模拟常见的多租户客服 SaaS，敏感信息存于 SQL 表。
-入口：攻击者打开新工单，正文分两块------上半段是客服问题，下半段是 "致 Cursor agent 的紧急指令"，明确要求把 integration_tokens 表内容写回同一工单。
-触发：开发者在 Cursor 里随口问句 "列一下最新 open 的 ticket"。
-劫持：Cursor agent 解析到攻击者的隐藏指令，连续调用 list_tables → execute_sql，把整表数据写进公开消息；操作日志里能看到多次 execute_sql 调用，却没人注意。
-收割：攻击者刷新页面，即刻获取 4 条完整令牌记录（ID、客户 ID、Provider、Access Token、Refresh Token、Expires），相当于拿到后台钥匙。 3）为什么它吓人，以及接下来怎么办 这类攻击无需"提权"------它直接利用 Prompt Injection 撞开了 Cursor MCP 自动化通道；任何把生产数据库暴露给 MCP 的团队，理论上都可能中招。 Supabase、Postgres、MySQL 都一样，只要 agent 拥有查询权限，攻击者就能"借刀杀人"。更糟的是，工单、评论、聊天窗口都能成为隐形载体，WAF 和 RBAC 根本感知不到。 如果你正在用 Cursor + MCP 直连生产库，立即： 关掉 MCP 对数据库的写权限或彻底隔离读写。 加审：强制人工审查 agent 的 plan / SQL 调用。 清洗：对外部输入做最严格的内容过滤，屏蔽 "######## Instructions for Cursor#######" 之类模板。