人工智慧
為何一個典型的 MCP 伺服器漏洞會破壞您的整個 AI 代理?
光靠一個小小的 Anthropic SQLite MCP 伺服器 SQL 資料隱碼攻擊 (SQL Injection) 漏洞，就可以讓駭客植入預先儲存的提示、將資料外傳，並且駭入整個 AI 代理工作流程，而這漏洞已經被分支複製了 5,000 多次。本文說明其攻擊過程，並提供一些具體的修正方法來加以防範。
重點摘要
- 軟體供應鏈的衝擊半徑相當廣，含有漏洞的 Anthropic SQLite MCP 伺服器在被封存之前已被分支複製了 5,000 次以上。這意味著，這套未修補的程式碼正存在於數以千計的下游 AI 代理當中，其中許多很可能已經進入了營運環境，它們默默承接了 SQL 資料隱碼攻擊的風險，並且可能讓漏洞攻擊擴散至整個 AI 代理。
- SQLite MCP 伺服器的漏洞可能影響數以千計的 AI 代理，傳統的 SQL 資料隱碼攻擊打開了一個快速注入預先儲存提示的全新路徑，讓駭客直接操控 AI 代理，大大提高了攻擊成功機率。
- SQL 資料隱碼攻擊漏洞可讓駭客透過工作流程之間的預設信任來提升權限。一般來說，AI 代理通常都信任來自內部的資料，不論是資料庫、記錄檔，或是快取的記錄，AI 代理通常會將它視為安全無害。駭客可利用這項信任來嵌入一個提示，就能讓 AI 代理呼叫一些強大的工具 (電子郵件、資料庫、雲端 API) 來竊取資料或進行橫向移動，而這一切都避開了前期的資安檢查。
- 目前官方並無任何修補更新的規劃，因此開發人員必須自己設法修正這項問題。企業若正在使用未經修補的分支版本，就有可能會發生資料外洩與服務中斷而面臨重大的營運和商譽風險。本文提供了一份建議修正清單來協助防範這項漏洞。
Trend™ Research 發現了一個簡單但卻相當危險的漏洞：Anthropic SQLite Model Context Protocol (MCP) 伺服器參考實作當中的一個典型 SQL 資料隱碼攻擊 (SQL Injection) 漏洞。儘管這個 GitHub 儲存庫已於 2025 年 5 月 29 日封存，但在封存之前卻已經被分支或複製了超過 5,000 次。 很重要的一點是，官方已表明這份程式碼只是一份參考實作，非供營運使用。
含有漏洞的程式碼有可能讓駭客執行未經授權的指令、注入惡意提示、竊取資料，以及挾持 AI 代理的工作流程。 本文探討這項漏洞位於何處、它會造成什麼影響，以及該如何加以防範。
漏洞在哪裡？
這項漏洞存在於原始程式碼處理使用者輸入的位置。它會直接將未淨化的使用者輸入內容串接成一道 SQL 敘述，接著交由 Python 的 sqlite3 驅動程式來執行，完全不經任何過濾或檢查。圖 1 顯示造成這個核心 SQL 資料隱碼攻擊漏洞的非參數化輸入。
此漏洞會帶來嚴重的資安風險，更確切一點，就是創造了 SQL 資料隱碼攻擊 (SQLi) 的完美條件，駭客可利用該漏洞來將惡意的查詢敘述嵌入系統內。
OWASP 的「SQL 資料隱碼攻擊防範快速指南」 (SQL Injection Prevention Cheat Sheet) 十多年來不變的第一項建議就是：使用參數化查詢。這樣做可以從設計上防範 SQLi 漏洞攻擊，讓資料庫能正確區分「資料」和「程式碼」。若忽視這項最佳實務原則，就等於重新開啟一系列典型的 SQL 攻擊，包括：迴避認證、資料外傳、篡改，甚至是經由 SQLite 虛擬表格技巧寫入任意檔案。
簡單的 SQL 資料隱碼攻擊如何挾持客戶支援機器人
以下說明這項漏洞如何被駭客利用。在我們的範例中，客戶支援 AI 代理負責從 SQLite MCP 伺服器讀取客戶支援問題單。首先，客戶透過網站來提交問題單，接著，擁有權限的支援工程師 (或機器人) 會將所有被標記為「開放」的問題單進行分類。圖 2 顯示當駭客偷偷將 SQL 資料隱碼攻擊惡意內容塞入客戶支援 AI 代理時會發生什麼情況。
以下逐步說明駭客的攻擊步驟：
- 駭客提交問題單。
圖 3 顯示當問題單的內文欄位含有被駭客注入的 SQL 敘述時，整個 SQL 查詢敘述看起來如何。由正常的支援問題單請求所建立的 SQL 敘述應該只到第 5 行為止。然而，被注入的內容 (第 5 行至第 11 行反白部分) 會先利用一個假的問題單來結束第一道 SQL 敘述，然後再建立一個新的問題單，內含預先儲存的惡意提示。
- 透過含有漏洞的 SQLite MCP 伺服器來儲存惡意提示。
- 支援工程師或機器人使用 AI 代理來對「開放」問題單進行分類。
- AI 模型依照提示中的指示執行作業。
這可說是 LLM 版本的預先儲存 XSS 攻擊，一般稱為「預先儲存提示注入」，這是 LLM 環境眾所周知的頭號風險。SQLite MCP 伺服器的漏洞會讓 AI 代理將惡意提示儲存成「開放」狀態，等於避免了後端安全機制為了防範提示注入而將它分類為「待處理的問題單」。
分類時，支援工程師或機器人會經由 AI 代理來讀取含有惡意提示的問題單，並將它當成正常問題單來處理。
預先儲存的提示會指示 LLM 呼叫一些內部工具，如電子郵件用戶端或另一個 MCP 伺服器，這些工具在高權限的環境下被允許使用。在此處的範例中，這會將客戶資料 (customer.csv) 發送至駭客的電子郵件地址 (attacker@evil.com)。
由於電子郵件 MCP 工具是以較高的權限執行，而分類工作流程卻盲目地相信任何標示為「開放」的問題單，因此，只需一道注入提示，再搭配預先儲存的提示，就能入侵系統並橫向移動或將資料外傳。
在一個仰賴 MCP 伺服器來儲存和擷取資訊的 AI 代理環境，這個看似微不足道的 SQLi 漏洞再也不單只是資料層面的問題，而是變成了預先儲存提示注入的跳板，讓駭客能夠指揮 AI 代理執行一些高權限動作、將資料竊取自動化，並且橫向移動。
漏洞揭露與現況
2025 年 6 月 11 日，我們在負責任的揭露原則下向 Anthropic 私下通報了這項問題。但 Anthropic 在回覆中表示，該儲存庫是一個已封存的示範實作，因此認定該漏洞已超出受理範圍。截至本文撰寫為止，根據 GitHub 問題第 1348 號當中的討論，目前並無任何修補更新的計畫。此外，所有底下的 Anthropic 參考實作也都已封存。
快速修正檢核清單
由於官方對已封存的儲存庫並無任何修補更新的計畫，因此保護實作安全的大部分責任就落在開發人員和開發團隊身上。本文列出一份快速修正檢核清單來協助開發人員在自己的 SQLite MCP 伺服器分支或部署環境當中尋找及修補此漏洞：
- 將所有 f 字串 (f-string) 換成預留位置來手動修正含有漏洞的 SQLite MCP 伺服器：檢查您是不是在 2025 年 5 月 29 日之前建立 Anthropic SQLite MCP 伺服器的分支，還是您正在使用任何已封存的版本。請找出每一個可找到的「_execute_query」呼叫，然後強迫改用參數化執行方式來替代，如下所示。
# vulnerable results = db._execute_query(arguments["query"]) # quick patch sql, params = arguments["query"], tuple(arguments.get("params", [])) if";" in sql: # simple single-statement guard raise ValueError("stacked queries blocked") results = db._execute_query(sql, params) # Use parameterized input - 幫「SELECT … FROM {table}」這類敘述中的表格名稱建立白名單。
- 禁止經由 sqlite3 組態設定來堆疊敘述 (使用 isolation_level=None 可關閉內建的自動提交 (autocommit) 功能，但您仍需要執行輸入檢查)。
- 監控是否有異常的提示離開您的 LLM 邊界 (例如：生成的 SQL 含有非預期的「SELECT * FROM users」敘述，或者負責分類的 AI 代理突然發送大量電子郵件)。
結論與建議
這起事件再次讓一個老舊的問題浮上檯面：典型的輸入淨化漏洞一旦藏在 AI 代理背後，問題就不單只侷限於資料層面。光這一個 MCP 伺服器非參數化字串，就可能牽連數以千計的下游分支版本，甚至進入到私人專屬的程式碼資料庫，最終在一些高權限的環境中觸發自動化工作流程。當駭客將一個教科書級的 SQLi 漏洞變成一個預先儲存提示注入漏洞時，LLM 後續的每一次呼叫都有可能被駭客的指示所控制，不論是讀取客戶記錄、發送電子郵件，或是橫向移動到鄰近的系統。
結論很明顯，如果我們讓昨日的網站應用程式錯誤不小心滲透到今日的 AI 代理基礎架構當中，那就等於讓駭客輕鬆透過 SQL 資料隱碼攻擊全面入侵 AI 代理。要消除這項漏洞，就需要一些程式設計紀律、自動化供應鏈監控，以及執行時期安全機制，並且假設任何預先儲存的內容 (不論其來源為何) 都可能有問題。
除了前面提到的快速修正檢核清單之外，以下是一些有助於防範這類漏洞的最佳實務原則：
- 重新檢視 OWASP 的「SQL 資料隱碼攻擊防範快速指南」。如前面提到，OWASP 長久以來一直建議使用參數化查詢作為防範 SQLi 漏洞的首要防禦。這一點應該被視為一項基本實務，尤其在與 LLM 或代理式系統整合時。
- 稽核 AI 代理工作流程，檢查看看是否有隱藏的預設信任。假使 AI 代理預設將內部資料視為安全無害，那就有可能發生預先儲存提示注入的問題。檢查一下 AI 會在何時、透過何種方式讀取和解讀使用者產生或系統儲存的輸入內容並執行任何行動。
- 限制高權限環境對工具的存取。不應允許 AI 代理毫無限制地存取電子郵件、檔案系統或外部 API。導入驗證步驟、核准機制或沙盒模擬環境，以便在發生這類漏洞攻擊時降低衝擊。
- 監控異常狀況。隨時留意是否有可疑的提示、非預期的 SQL 指令，或是異常的資料流動，例如 AI 代理在標準作業流程之外對外發送電子郵件。