Cursor IDE 任意程式碼執行漏洞

透過惡意 Git 二進位檔進行任意程式碼執行

Cursor IDE 包含一個漏洞，允許在 Windows 系統上無需使用者互動即可進行任意程式碼執行 (ACE)。當 Cursor 載入專案時，其路徑解析邏輯會在多個位置搜尋 Git 二進位檔，包括目前的開發工作區根目錄。如果攻擊者在儲存庫的根目錄放置一個名為 git.exe 的惡意執行檔，Cursor 將會在正常運作期間自動執行它。

此漏洞並非一次性事件；只要專案保持開啟狀態，Cursor 就會以一定的頻率重複呼叫該二進位檔，這使得攻擊者能夠在沒有任何提示、核准對話框或警告的情況下，維持持久性或多次執行指令。

技術根本原因與概念驗證

此漏洞源於 Cursor 的 Git 二進位檔查找過程。IDE 嘗試尋找 git 指令以執行版本控制操作。由於其搜尋路徑包含了工作區目錄，因此它會優先使用本地的 git.exe 而非系統層級的 Git 安裝。

Mindgard 使用了一個無害的概念驗證來展示此漏洞：將 Windows 計算機應用程式重新命名為 git.exe 並將其放置在儲存庫根目錄中。在 Cursor 中開啟專案時，IDE 會自動啟動多個計算機應用程式實例。Sysinternals Process Monitor 日誌證實了 Cursor.exe 會透過指令行 git rev-parse --show-toplevel 發起該本地 git.exe 的程序建立過程。

緩解措施與防護策略

在 Cursor 發布正式修補程式之前，使用者與管理員應實施以下防護措施：

給企業與受管理之 Windows 系統

管理員應使用 AppLocker 或 Windows App Control 策略來防止從開發者工作區目錄執行二進位檔。建議使用基於路徑的拒絕規則，而非基於雜湊值的規則，以應應對變動的攻擊者二進位檔。建議的規則範圍為：%USERPROFILE%\source\repos\*\filename.exe。

給個人開發者

避免在主機上開啟未經信任的儲存庫。建議改用隔離的環境，例如：

• Windows Sandbox
• 隔離的虛擬機器 (VMs)
• 可拋棄式開發容器

揭露時程與廠商回應

Mindgard 於 2025 年 12 月 15 日首次發現並回報此漏洞。儘管在七個月內多次嘗試協調修復，但在測試到 2026 年 4 月 30 日為止的版本（版本 3.2.16）中，該問題仍未獲得修補。

根據揭露時程，回報過程遇到了幾項失敗：

• 初始回報： 於 2025 年 12 月 15 日透過官方 security.txt 電子郵件發送。
• Triage（分流）： 在 LinkedIn 上進行公開接觸後，Cursor CISO 承認了 HackerOne 工作流中的自動化失敗，並於 2026 年 1 月 15 日手動邀請研究人員加入漏洞獎金計畫。
• 確認： HackerOne 重現了該問題，並於 2026 年 1 月 20 日確認已送達 Cursor。
• 沈默： 從 2026 年 2 月到 6 月，透過 HackerOne 的多次更新請求以及直接聯繫領導層的嘗試均未獲得回應。

社群群體觀點與反論點

在公開揭露之後，開發者社群針對漏洞的嚴重程度與性質提出了幾點看法：

反對高嚴重程度的論點

部分使用者認為此漏洞的嚴重性較低，因為它需要攻擊者已經在使用者的檔案系統中放置了檔案。一位評論者指出：

"An actor has to place a malicious .exe in the user's code folder, named git.exe, for this to take place... if they've placed something in your filesystem like that already, you've already been compromised."

其他人則建議，只要這些安全性功能未被停用，Windows 存取控制清單 (ACLs) 或未簽署應用程式的警告可能會減輕其影響。

支持高嚴重程度的論點

其他貢獻者指出，對於從公開來源複製（clone）受損儲存庫的使用者來說，這是一個常見的攻擊向量。風險在於，一個旨在處理未經信任程式碼的 IDE——一個處理未經信任程式碼的工具——不應該在沒有使用者明確同意的情況下，自主地執行來自該程式碼內部的二進位檔，無論使用者是否已在 IDE 的工作區信任對話框中點擊了 "Trust this folder"。

系統性擔憂

討論也涉及了 AI 驅動開發工具更廣泛的影響。有些人質疑為什麼會存在這樣的特性，並對快速增長與高估值的 AI 部門表示擔憂，認為這可能導致公司忽住院性的安全性衛生與及時的漏洞揭露流程。