在人工智慧輔助程式設計（AI Coding Assistant）成為開發者常用工具的年代，一種新的的新型態安全漏洞「IDEsaster」在 2025 年底由資安研究員 Ari Marzouk (MaccariTA) 所揭露，根據他的研究指出，我們熟知的許多 AI 程式碼助手（如 GitHub Copilot、Cursor、Windsurf 等）可能因為「過度熱心」與 IDE 的底層功能結合，反而成為駭客入侵開發者電腦的跳板。
這不僅僅是單一軟體的 Bug，而是一個全新的攻擊類別（Vulnerability Class），我們來看看 IDEsaster 的運作原理、受影響的工具，以及目前各大廠商的最新回應與修補狀況。
什麼是 IDEsaster？
過去我們對 AI 安全的擔憂主要集中在「提示注入（Prompt Injection）」，例如誘騙 AI 說出不該說的話。但 IDEsaster 將這種攻擊提升到了「執行層面」。簡單來說，IDEsaster 利用了 AI Agent（代理人）與「傳統 IDE 功能」之間的信任缺口。藉由這種攻擊入口，駭客在開源專案的 README、程式碼註解或設定檔中隱藏惡意指令（Prompt Injection）。接著，當開發者使用 AI 助手（如 Cursor 或 Copilot）讀取該專案時，AI 會解析這些指令，並執行。
在這個階段時如果觸發地雷，AI 會依照指令，去修改 IDE 的「底層設定檔」，比方說我們熟悉 VS Code 的 .vscode/settings.json 或 JetBrains 的 .idea/workspace.xml。這樣會有怎樣的後果呢 ? 這些看似無害的設定修改，實際上可能將 IDE 的執行路徑（Executable Path）指向駭客的惡意腳本，導致遠端程式碼執行（RCE） 或敏感資料外洩。
這項發現最驚人的地方在於，它不需要 AI 工具本身有傳統意義上的漏洞，而是利用了 IDE 本來就有的「合法功能」（例如自動執行某些路徑的工具），配合 AI 的自動化能力來達成攻擊。
受影響的工具與相關 CVE
根據目前揭露的資訊，幾乎所有基於 VS Code 或 JetBrains 核心構建的 AI IDE 都受到了影響。以下是截至 2025 年 12 月中旬的最新 CVE 發展整理：
| 受影響工具 | 漏洞類型 | CVE 編號 | 狀態/備註 |
| Cursor | RCE (敏感檔案覆寫) | CVE-2025-49150 | 已修補。涉及繞過大小寫檢查覆寫設定檔。 |
| RCE (工作區設定竄改) | CVE-2025-61590 | 攻擊者可透過聊天上下文劫持來修改 .code-workspace 檔案。 | |
| RCE (CLI 設定竄改) | CVE-2025-54130 | 涉及 .cursor/cli.json 的修改。 | |
| GitHub Copilot | RCE (設定檔注入) | CVE-2025-53773 | 允許透過 Prompt Injection 修改 IDE 設定以執行本地代碼。微軟初期將此評為中風險。 |
| RCE (多重根目錄設定) | CVE-2025-64660 | 利用 Multi-Root Workspace 功能進行攻擊。 | |
| Roo Code | 資料外洩 / RCE | CVE-2025-53097 CVE-2025-53536 | 涉及利用遠端 JSON Schema 進行資料外洩及設定檔 RCE。 |
| JetBrains Junie | 資料外洩 | CVE-2025-58335 | 透過惡意 Schema URL 觸發 GET 請求洩漏資訊。 |
| Zed.dev | RCE | CVE-2025-55012 | 類似的設定檔覆寫攻擊路徑。 |
註：AWS 相關產品也被提及在受影響名單中（如這篇 AWS-2025-019），但具體細節仍需等待官方更詳細的公告確認。
攻擊是如何發生的？
該項資安研究中展示了三種主要的攻擊場景：
遠端 JSON Schema (資料外洩)： 攻擊者誘騙 AI 寫入一個指向惡意網址的 JSON Schema。當 IDE 嘗試驗證這個 JSON 檔時，會自動向該網址發送請求，駭客便能透過 URL 參數竊取敏感資訊。
IDE 設定覆寫 (RCE)： 攻擊者誘騙 AI 修改 .vscode/settings.json，例如將 PHP 的驗證執行檔路徑（php.validate.executablePath）指向專案內一個隱藏的惡意腳本。當開發者打開 PHP 檔案時，IDE 就會自動執行該腳本。
多重根目錄工作區 (Multi-Root Workspace)： 這是針對 VS Code 的進階攻擊。攻擊者利用 AI 修改 .code-workspace 檔案，不僅可以改變設定，還能重新定義工作區的根目錄，從而繞過某些路徑存取的限制。
各方回應與積極應對
1、微軟與 GitHub 的態度
微軟在處理這類漏洞時顯得相對謹慎。對於部分 Copilot 的漏洞（如 CVE-2025-53773），微軟最初給予了「中等（Medium）」的嚴重性評級，認為這需要使用者一定程度的互動（如接受 AI 的建議）。然而，資安社群普遍認為，在 AI Agent 模式下，「使用者互動」的界線正變得模糊，因為 Agent 往往被設計為可以自主行動。
此外，針對早先的 CamoLeak 問題（利用 GitHub Image Proxy 竊取資料），GitHub 已經採取了激進措施，直接禁用了 Copilot Chat 中的圖片渲染功能來阻斷攻擊鏈。
2、開源社群與新創工具的快速修補
像 Cursor 和 Roo Code 這類新創 AI 編輯器，由於功能迭代極快，受到的影響也最直接。它們反應迅速，但在修補過程中也發現了許多「回歸漏洞（Regression）」，例如 Cursor 的 CVE-2025-32018 就是一個修補後又再次出現的寫入權限問題。這顯示了在快速發展的 AI 功能與安全性之間取得平衡極具挑戰性。
3.、Secure for AI 原則的提出
研究員 MaccariTA 提出了一個核心觀點，他認為目前的 IDE 並不是為了 AI 設計的（Not Secure for AI）。 過去我們認為「使用者手動修改設定檔」是安全的，但當 AI 代理人可以代勞時，這個假設就不成立了。未來的軟體架構必須採用「Secure for AI」原則，明確區分「人類操作」與「AI 操作」的權限邊界。CyberQ 也相當認同，如果人類需要更好的 AI 開發工具，可能在導入 AI 時，需要更適合 AI 環境的 IDE，所以 Secure for AI 原則是卻真價實的新議題，也正在發展中。
開發者該如何自保？
在各家廠商完全解決這些架構問題之前，CyberQ 建議相關用戶應該採取以下防護措施：
保持懷疑 (Zero Trust for AI)： 不要盲目信任 AI 讀取陌生專案後給出的操作建議，特別是涉及修改設定檔（.json, .xml, .yml）的動作。
限制 AI 權限 (Human-in-the-Loop)： 如果你的 AI 工具支援「人機協作模式（Human-in-the-Loop）」，請務必開啟。對於檔案寫入、終端機指令執行，最好都要經過人工確認。
小心陌生儲存庫： 在開啟來源不明的 GitHub 專案時，考慮使用沙箱環境（如 GitHub Codespaces 或隔離的 VM），避免直接在主力工作機上讓 AI 掃描程式碼。
CyberQ 提醒，由於這是 2025 年底剛爆發的漏洞潮，各大廠商（VS Code, Cursor, JetBrains）都在頻繁釋出安全性更新，請務必保持軟體在最新版本。
CyberQ 認為，IDEsaster 的出現意味著 AI 資安需要再檢視更多細節，當我們賦予 AI 更多工具去操作系統時，也同時有機會為駭客打開了更多的大門，按照資訊安全管理的原則與精神，最小權限原則，以及針對 AI 工具在系統與程式開發中該獲取的權限與相關漏洞避免都需要花時間確認與正確設定。這場關於便利性與安全性的拉鋸戰，在 2026 年恐怕只會更加激烈。
