MCP協議曝出重大漏洞：會泄露整個數據庫
責編：gltian ｜2025-07-11 17:43:18所有使用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