Cursor 開專案就可能執行惡意程式
Cursor 是整合 AI 程式碼生成、補全與 Agent 工作流的開發工具，但這次問題跟模型越獄或 prompt injection 無關，而是更傳統的執行檔搜尋路徑漏洞。Mindgard 指出，Windows 版 Cursor 開啟專案後會從多個位置尋找 Git binary，範圍竟包含目前 workspace；攻擊者只要把惡意程式命名為 git.exe 放在儲存庫根目錄，開發者一開啟專案，Cursor 就可能在沒有點擊、警告或核准視窗的情況下執行，而且還會定期重複呼叫。程式會繼承目前使用者權限，因此可能讀取原始碼、憑證或植入其他惡意程式。
現實應用
最直接的攻擊入口是陌生 GitHub 專案、面試作業、外包交付、開源套件範例，以及同事透過聊天軟體傳來的壓縮檔。個人開發者有風險，會大量拉取外部 repository 的企業研發、資安研究與供應鏈審查團隊更需要注意。這類情境甚至不必說服使用者執行腳本，單純「用 Cursor 看一下」就可能踩中。
期望評估
我認為低標期望是先把不受信任專案移到 Windows Sandbox、隔離 VM 或拋棄式環境，至少能降低主機上的 SSH key、雲端憑證與公司原始碼一起外洩的機率。
我猜高標期望是 Cursor 修正 binary resolution，禁止從 workspace 自動載入 git.exe，並補上可信任目錄、執行提示與安全公告。企業端若同步導入 application control，還能把同類型的「專案夾夾帶執行檔」攻擊一起壓下來。
商業策略分析
我認為受影響的不只 Cursor，也包含採用 AI IDE 的企業採購、資安團隊與競爭產品。AI 開發工具被授予終端機、程式碼與 secrets 存取權後，安全回應速度本身就是產品能力。Mindgard 表示漏洞自 2025 年 12 月通報、HackerOne 亦曾確認重現，但截至 2026 年 7 月公開揭露時仍未見修補或正式回應。對企業來說，值得立即盤點 Windows 使用量與外部 repository 流程；是否停用則應依端點控制與資料敏感度決定，不必把所有 AI IDE 一概封鎖。
實作細節
目前沒有安裝修補程式的資訊。Mindgard 建議個人只在隔離環境開啟陌生專案；受管 Windows 可用 AppLocker 或 Windows App Control，以路徑規則限制 workspace 內的可執行檔。規則應先用 Audit 模式驗證，避免正常開發工具被誤擋；單靠檔案 hash 封鎖效果有限，因為攻擊者可隨時更換 binary。