這篇文章要跟各位工程師分享一個關於 AI 編輯器 Cursor 以及其他 AI 開發工具在 Windows 平台上的嚴重安全漏洞。這個漏洞的核心在於一個經典的資安問題：不安全的搜尋路徑（Untrusted Search Path），而其結果是導致任意程式碼執行（Arbitrary Code Execution, ACE）。
簡單來說明這個漏洞是如何運作的，以及為什麼它對開發者來說非常危險。
漏洞原理：當 Git 變成陷阱
在 Windows 環境中，當一個程式想要執行某個指令（例如 git）但沒有指定完整路徑時，作業系統會根據一定的順序去尋找這個執行檔。通常它會先檢查當前的工作目錄（Working Directory），如果沒找到，才會去檢查系統環境變數 PATH 中定義的路徑。
Cursor 在開啟一個專案資料夾時，為了確認該專案是否為 Git 儲存庫，會嘗試執行 git rev-parse --show-toplevel 這個指令來獲取專案根目錄。
問題就在這裡：Cursor 在執行這個指令時，會先檢查專案的根目錄。如果攻擊者在儲存庫的根目錄中放置一個惡意的執行檔，並將其命名為 git.exe，Cursor 就會直接執行這個惡意的 git.exe，而不是系統路徑中真正的 Git 工具。
這意味著攻擊者不需要利用複雜的 Prompt Injection（提示詞注入）或欺騙 AI 模型，只要你 Clone（複製）了對方的儲存庫並用 Cursor 開啟，惡意程式就會立即在你的電腦上執行。
為什麼這對開發者非常危險
對於 junior 工程師來說，可能會覺得「我怎麼會去 Clone 陌生人的儲存庫？」但在實際開發中，我們經常會從 GitHub 上嘗試開源專案、下載範例程式碼或參考他人的實作。
一旦這個惡意 git.exe 被執行，它將擁有與你目前登入使用者相同的權限。這意味著攻擊者可以： 讀取你的所有原始碼。 竊取你的 SSH Keys（用於伺服器登入的金鑰）。 拿走你的雲端平台 Token（例如 AWS 或 GCP 的金鑰）。 在你的系統中植入後門。
最糟糕的是，只要專案開啟著，Cursor 可能會反覆觸發這個執行過程，讓惡意程式持續運行。
不只是 Cursor，這是一個系統性問題
根據安全公司 Mindgard 與 Cymulate 的研究，這個問題不僅限於 Cursor。GitHub Copilot CLI、Gemini CLI 以及 Codex 等 AI 工具在 Windows 上都表現出類似的行為：它們在啟動或開啟資料夾時，會優先在工作目錄中尋找輔助執行檔。
儘管研究人員向多家廠商回報，但反應不一。有些廠商將其視為低風險，甚至認為「如果攻擊者能把檔案放進你的資料夾，他已經擁有系統權限了」，但這完全忽略了開發者 Clone 外部儲存庫這一極其常見的行為。
目前如何防禦
由於目前許多工具尚未提供官方補丁（Patch），身為開發者，我們必須採取主動防禦措施。
第一，不要信任任何外部儲存庫。在開啟一個不熟悉的專案之前，先檢查根目錄中是否包含不應該存在的執行檔，例如 git.exe, npx.exe, node.exe 或 where.exe。正常的專案根目錄不應該包含這些系統工具。
第二，使用隔離環境。強烈建議在 Windows Sandbox（Windows 內建的沙盒）或 disposable VM（可隨時刪除的虛擬機）中開啟未經信任的專案。這樣即使觸發了惡意程式，影響範圍也僅限於隔離環境，不會危及你的主機與金鑰。
第三，企業級防禦。對於公司內部的管理電腦，可以使用 AppLocker 或 Windows App Control 設定規則，禁止在使用者專案路徑（例如 %USERPROFILE%\source\repos\*）下執行任何 .exe 檔案。
總結
這個漏洞提醒我們，即使是在使用最先進的 AI 工具時，底層的作業系統行為（如檔案搜尋順序）依然是最大的安全漏洞來源。請記得：任何從網路上下載並開啟的儲存庫，在本質上都應該被視為可執行內容，而非單純的文字檔案。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。