Cursor 0day：當完整揭露成為唯一保護手段
作者：Aaron Portnoy（Mindgard） · 2026 年 7 月 14 日發布
有時候資安研究會挖出極為技術性的漏洞，需要好幾頁篇幅才解釋得清楚。但這次不是那種案例。
這個 bug 非常簡單。開發者在 Windows 上用 Cursor 開啟一個儲存庫，只要該儲存庫的根目錄裡含有一個惡意的 git.exe，Cursor 就會自動執行它。沒有任何點擊、提示、同意對話框或警告，結果就是任意程式碼執行。
考量到 Cursor 是目前採用最廣泛的 AI 輔助開發環境之一（超過 700 萬活躍用戶、每日 100 萬、付費用戶 100 萬、5 萬家企業使用），且據報其市值已達 600 億美元，合理推測該公司對資安實務應有一定程度的重視，但這個漏洞顯示情況完全相反。
此漏洞由 Mindgard 於 2025 年 12 月 15 日首次發現，當日即回報，此後又多次回報。事隔六個多月、釋出 197 個以上新版本後，問題在最新測試版本中仍然存在。
漏洞本身的技術細節
這個漏洞並非理論性，也不依賴複雜的攻擊鏈、提示注入、模型操控、越獄、記憶體破壞或精密的攻擊手法。攻擊者只需要開發者開啟一個專案根目錄含有 git.exe 二進位檔的儲存庫即可。
技術問題本身極其直觀。Cursor 載入專案時，會嘗試從多個位置尋找 Git 二進位檔，其中一個位置就是工作區本身。
如果攻擊者在儲存庫根目錄植入一個惡意的 git.exe，Cursor 會在路徑解析過程中自動執行它，不會有任何警告、同意或即將執行儲存庫內可執行檔的提示。
為了安全地展示問題，Mindgard 使用了一個無害的概念驗證：把 Windows 小算盤重新命名為 git.exe，放進儲存庫根目錄。只要用 Cursor 開啟這個專案，就會自動執行它。
下方截圖顯示了結果。畫面上多個小算盤視窗並非研究人員手動開啟的，Cursor 在專案保持開啟的狀態下會反覆重新執行這個重新命名的二進位檔，隨著時間經過出現越來越多視窗。換言之，這不是一次性啟動事件，也不是使用者觸發的動作。Cursor 在正常運作期間會反覆從工作區內部呼叫可執行內容。
在真實攻擊情境中，小算盤會被替換為攻擊者控制的程式碼，導致任意程式碼以目前使用者權限執行。
最後驗證日期為 2026 年 4 月 30 日，測試對象為 Windows 上的 Cursor 3.2.16 版本。Sysinternals Process Monitor 顯示 Cursor.exe 在工作區中建立了一個 Process Create 事件，PID 48972 成功執行 git.exe。
這個漏洞的簡單程度近乎無聊，而這可能才是最令人擔憂的部分。Cursor 在正常運作期間會執行儲存庫中由攻擊者控制的二進位檔，且完全不需要使用者互動。如此直觀的問題竟能持續數月而不修復，這個事實應當讓每一位目前正在部署 Cursor 的個人和組織感到憂心。
為什麼這次揭露與眾不同
大多數的協調揭露遵循以下熟悉的模式：
- 漏洞被回報
- 對話展開
- 嚴重性被討論
- 工程團隊進行調查
- 修復被開發出來
- 使用者受到保護
- 公開揭露隨後發布
這個流程之所以有效，是因為所有參與者共享一個共同目標：降低風險。
但很遺憾的是，這個案例從未進入風險降低的階段。七個月過去了，沒有任何廠商實質參與，現在該質疑的是：像這樣簡單但影響重大的漏洞，是否還會得到修復。
資安研究人員理解修復需要時間，特別是在大型且快速演進的軟體平台中。然而，當數月過去卻沒有任何溝通、更新或可見的進度時，耐心就難以合理化。使用者理應受到針對基本威脅的基本保護，當廠商停止溝通卻仍持續分發受影響的軟體時，研究人員最終面臨一個兩難的抉擇：
- 保持沉默，讓使用者在錯誤的安全假設下運作。
- 公開揭露，讓組織能做出有依據的風險決策。
使用者值得擁有這些資訊。完整揭露是漏洞揭露中的「核選項」，保留給所有其他途徑都已失敗的情境。它存在有它的道理：當廠商停止溝通時，使用者不該被蒙在鼓裡。
為什麼我們選擇完整揭露
和許多資安研究團隊一樣，Mindgard 偏好協調揭露。目標永遠是「安全第一、宣傳第二」。
但協調揭露只有在「有人協調」時才有效。從首次揭露至今已過七個月，我們沒有任何跡象顯示使用者正受到保護、修復正在進行中，或受影響的組織已被通知。在這個節點上，繼續隱瞞資訊已不再服務使用者，而是服務於沉默。
因此，Mindgard 決定釋出此漏洞的完整細節。使用 Cursor 的組織應有機會評估自身曝險、實施補償性控管，並對其資安態勢做出有依據的決策。
使用者安全必須擺在第一位，即使揭露令人不舒服。 尤其是當揭露令人不舒服時。
業界更大的問題
這次揭露的意義超越一個名為 git.exe 的可執行檔，觸及軟體信任的本質。AI 公司常態性地要求使用者授予前所未有的存取權限——存取程式碼、儲存庫、終端機、機密資訊，以及日益模糊「建議」與「行動」界線的工作流程。
產業敘事是：這些系統值得信任，因為它們提升生產力。但歷史一再告訴我們，信任不應僅僅因為「有用」就給予，信任應透過行為來爭取。那個行為反映在公司如何回應資安報告、如何與受影響的使用者溝通，以及如何優先處理修復上。
當直觀的漏洞持續多月仍未解決且缺乏有意義的溝通時，使用者被迫重新評估對這些系統的信任假設。
7 個月揭露時間軸
| 日期 | 動作 |
|---|---|
| 2025/12/15 | Mindgard 發現漏洞 |
| 2025/12/15 | 回報至 [email protected] |
| 2025/12/18 | 請求確認收件 |
| 2026/01/13 | Mindgard 在 LinkedIn 發文請求 Cursor 對口；CISO 在留言中被提及 |
| 2026/01/15 | Cursor CISO 回信承認內部自動化失敗導致 HackerOne 流程未啟動；手動邀請 Mindgard 加入漏洞獎勵計畫 |
| 2026/01/15 | 漏洞透過 HackerOne 重新提交 |
| 2026/01/16 | 報告被初判為「告知性、範圍外」並關閉 |
| 2026/01/16 | Mindgard 提出異議 |
| 2026/01/16 | 報告重現成功後重新開啟 |
| 2026/01/20 | HackerOne 確認已交付給 Cursor |
| 2026/02/16 | 請求進度更新，無回應 |
| 2026/03/03 | 請求進度更新，無回應 |
| 2026/03/17 | 直接聯繫 Cursor CISO 請求更新 |
| 2026/03/18 | HackerOne 表示已聯繫 Cursor |
| 2026/04/01 | 請求進度更新，無回應 |
| 2026/04/01 | HackerOne 確認 Cursor 沒有更新 |
| 2026/06/01 | Mindgard 通知 HackerOne 將公開揭露 |
| 2026/06/03 | HackerOne 提供揭露指引 |
| 2026/07/14 | 本篇文章公開發布 |
為什麼這件事重要
這是 AI 輔助開發工具時代一個典型警訊。Cursor 估值 600 億美元、擁有 700 萬活躍用戶，卻對一個「連小算盤都能重現」的任意程式碼執行漏洞沉默 7 個月。期間釋出 197+ 個版本，每個版本都讓攻擊面持續存在。
更深層的問題是：當漏洞回報平台（HackerOne）本身已因 AI 產出的低品質報告而塞車時，真正高風險的漏洞也跟著被淹沒。HN 討論串中多位資深研究員指出，CVE 流程與漏洞揭露管道正面臨「AI 報告海嘯」的結構性壓力，企業端缺乏區分雜訊與真實威脅的處理能量。
對企業 IT 與資安團隊的實務建議：
- Windows 受控環境：用 AppLocker / Windows App Control 的「路徑型」拒絕規則（如
%USERPROFILE%\source\repos\*\filename.exe），不要用雜湊黑名單（攻擊者可換 hash） - 個人開發者：未修補前，只在隔離 VM / Windows Sandbox / 拋棄式環境中開啟不信任的儲存庫
- 採購評估：將「資安回應速度」列入 AI 編碼工具選商評分（Mindgard 揭露的 7 個月沉默是警訊）
🚨 數據解讀
- 197+ 版本 × 7 個月：漏洞從首次回報到完整揭露，Cursor 發布了 197 個以上版本，期間使用者完全沒有被告知風險
- 5 萬企業 × 700 萬用戶：受影響範圍遠超一般 CVE 個案，這不是單一使用者的問題，是企業供應鏈風險
- 70 次以上無回應：Mindgard 與 HackerOne 多次追蹤、嘗試升級、聯繫領導層，全部石沉大海
- 同時間其他 Cursor 漏洞：2026 年 Cursor 至少還被揭露 CVE-2026-26268（CVSS 8.1，git hooks 路徑）、CVE-2026-50548/50549（DuneSlide，prompt injection 升級為 RCE）等多個高嚴重性漏洞——這不是個案，而是系統性問題
編按：本文綜合整理自 Mindgard 原始揭露報告、Hacker News 討論串、Dark Reading 報導，並加入 Siami 編輯部觀點與數據分析。
網友熱門留言 (5)