實證研究發布於 AIA: 2026年5月3日

CursorJacking：惡意擴充功能如何偷走 AI 服務憑證

LayerX 報告指出，Cursor（AI 程式開發 IDE）把 API key 和工作階段 token 存在本機 SQLite 資料庫裡，而且任何已安裝的 Cursor 擴充功能（extension）都能讀到。這條攻擊不需要提示詞注入攻擊（prompt injection），也不需要使用者安裝後再點任何東西；一個看起來像 theme、helper 或生產力工具的擴充功能，就可能把 OpenAI、Anthropic、Google 或 Cursor 憑證偷走並外傳。真正的防線要落在三件事上：憑證要放進受保護的儲存機制；每個擴充功能要有清楚且會被系統落實的權限邊界；企業端也要統一管理 AI coding IDE 的擴充功能。

Credential TheftClient SecurityCredential GovernanceAI Coding IDEExtension Security

8 項對應的 AIDEFEND 防禦手法

來源: CursorJacking: Every Cursor User Is Vulnerable to API Key Theft by Rogue Extensions

作者: Roy Paz

原文發布: 2026年4月28日

威脅分析

憑證儲存沒有真正隔離保護。 LayerX 指出，Cursor 會把憑證存在 ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb，而不是放在 OS keychain、Windows Credential Manager 這類受保護的儲存機制後面。
任何已安裝的擴充功能，都可能讀取並偷走憑證。 惡意 theme、helper 或生產力擴充功能可以在 Cursor 的擴充功能環境裡執行，直接查詢本機 SQLite 資料庫；使用者不一定會看到明確的「我要讀取憑證」權限提示。
受影響的不只 Cursor 自己。 這個資料庫裡可能有 Cursor 工作階段 token，也可能有第三方 AI 供應商的 API key。這些憑證一旦被偷，攻擊者就可能冒用帳號、消耗付費 API 額度、查看提示詞和模型回應，甚至拿這些 key 去存取其他雲端或開發服務。
這是擴充功能供應鏈問題，不是模型行為問題。 使用者只要安裝一次擴充功能，後面就變成本機程式碼讀本機資料，再把結果送到攻擊者伺服器。模型沒有被 jailbreak，提示詞也不是主要攻擊面。
不要假設裝進 IDE 的擴充功能都可信。 Cursor 據報把已安裝擴充功能視為使用者本機環境的一部分，但對企業來說，重點是產品有沒有真的替每個擴充功能隔離 secrets、本機檔案和對外連線。工具看起來成熟，不代表這些邊界就已經落實。

適用的 8 項 AIDEFEND 防禦手法

AID-H-018.007

Skill-Level Permission Manifest Validation & Runtime Enforcement

極高

Cursor 擴充功能不該預設拿到整個 IDE 本機狀態的存取權。每個擴充功能都應該有機器可讀的權限清單，而且執行時要有一層檢查機制真的照清單擋下來：沒宣告的檔案讀取、受保護憑證路徑、對外網路目的地、shell 使用和高權限 IDE API，都要預設拒絕。一個 theme 擴充功能不應該能讀 state.vscdb，更不該能把內容送到網路上。

AID-M-001.003

Agentic Skill & Instruction Asset Inventory

高

企業需要集中盤點已安裝的 Cursor 擴充功能，以及其他 AI IDE 外掛：來源、發布者、版本、雜湊值、負責人、核准狀態、權限範圍、最後掃描時間和實際使用狀況。這份 inventory 負責找出受影響的機器與版本並送出 lifecycle finding；真正的停用、隔離或移除，仍由 admission 或 eviction 控制執行。

AID-I-007

Client-Side AI Execution Isolation

高

Cursor 是本機 AI coding IDE，所以安全邊界要包含擴充功能執行環境、本機應用程式狀態、憑證儲存位置，以及原生橋接層（native bridge，讓 IDE 裡的程式碼呼叫作業系統或桌面應用程式功能的通道）。client-side 隔離要讓不可信擴充功能碰不到 secrets、其他工作區狀態、作業系統資源或高權限應用程式 API；除非它明確需要，而且政策也核准。

AID-I-001.004

Sandbox Network Egress Restrictions

高

LayerX 描述的攻擊最後一步，是用簡單的對外請求把偷到的憑證送走。如果擴充功能執行環境有沙箱，預設拒絕對外連線、只允許少數核准目的地，就算擴充功能讀到機敏內容，也比較難直接外傳。

AID-H-004.002

Service & API Authentication

高

供應商呼叫應使用獨立的工作區或服務身分、短效且綁定 audience 的憑證與明確 route binding，不要把共用的組織層級 API key 放進開發者 IDE。這會限制被偷憑證繼續充當身分證明；資源授權與事件期間的撤銷仍由其他控制負責。

AID-E-001.001

Root & Long-Lived Credential Object Eviction

高

這次外洩的主要是長期有效的模型供應商 API key（OpenAI、Anthropic、Google）與雲端金鑰；一旦懷疑外洩，就要到權威簽發端停用或輪替這些確切 credential object。遭入侵的 Cursor session 與 IDE grant 分別由 AID-E-001.002、AID-E-001.004 撤銷，不能算成這項控制已完成。

AID-DV-002

Honey Data, Decoy Artifacts & Canary Tokens for AI

中

可以在合理但不會被正常流程使用的位置放 canary API key，用來偵測是否有惡意擴充功能或本機程序在掃描 secrets。這個 key 不能授予任何真實存取權；只要有人嘗試使用，就應該觸發高可信度警示，並帶上裝置、使用者、擴充功能和目的地資訊。

AID-D-005.007

Token, Tool-Use, Request-Parameter & Cost Spike Detection & Alerting

中

API key 被偷之後，其中一個直接後果就是付費 API 被濫用。針對每把 key 監控費用暴增、異常模型使用、新地理位置、可疑請求參數和像重放攻擊的流量，可以在帳單變大或資料事件擴大前，先看出憑證可能已經外洩。

身為資安防禦者，我們應該這麼做

盤點 Cursor 和其他 AI coding IDE 的安裝狀況，列出每個已安裝擴充功能的來源、版本、發布者、宣告權限，以及它是否跑在持有 AI 供應商 key 或雲端憑證的機器上。
把 API key、工作階段 token、refresh token 和供應商憑證，從可讀的本機資料庫或設定檔移出來。優先使用 OS keychain、加密 secrets 儲存、短效 token，以及登出或解除安裝時的清理流程。
在處理機敏工作的開發者機器上，擋下未核准的擴充功能。至少要把實驗性擴充功能測試，和含有真實客戶資料、正式環境存取權或付費 AI 供應商 key 的工作區分開。
替擴充功能執行環境加上檔案和網路邊界。除非擴充功能的權限清單明確需要、政策也核准，否則不應該能讀取憑證資料庫、雲端 CLI profile、.env 檔、SSH key 或 secrets manager。
加入針對本機讀取與對外連線的偵測：擴充功能程序開啟 Cursor 憑證儲存位置、未知擴充功能對外送資料、供應商 key 從新地點被使用，以及 API 費用或模型使用量突然暴增。
如果憑證可能已經外洩，立即輪替受影響的 OpenAI、Anthropic、Google、Cursor 和雲端 key；撤銷有效工作階段；檢查供應商最近使用紀錄；移除任何無法連回可信來源與負責人的擴充功能。

1 個額外的防禦考量

無法隔離擴充功能的 AI IDE，要有企業端使用政策

除了上面對應的防禦技術，團隊也應該把 AI coding IDE 當成一種端點平台來管理。如果某個 IDE 沒辦法把擴充功能和憑證儲存隔開，企業政策就要更嚴格：不要在裡面放正式或高機敏 API key，不要讓裝有未核准擴充功能的工作站處理 secrets，實驗用擴充功能也要和正式工作環境分開。

建議做法: 依照每個 AI IDE 會存哪些本機 secrets、能不能限制單一擴充功能的檔案和網路存取，替工具分級。只有在受核准版本、受保護憑證儲存、受管理擴充功能 allowlist 和對外連線監控都到位時，才允許使用真實供應商 key。

結論

CursorJacking 提醒我們，AI IDE 的風險不一定來自模型失控，也不一定來自使用者核准了危險提示詞。這次問題更直接：本機擴充功能能讀到原本應該被隔離保護的憑證。AIDEFEND 在這裡對應到的防線很清楚：保護客戶端憑證、治理已安裝的 skill 和擴充功能、落實每個擴充功能自己的權限、隔離 client-side 執行環境、監控 key 被濫用的跡象，並快速撤銷已外洩憑證。