Claude Code 安全：Cursor 後門事件自查指南

如果你有在用 Cursor（AI 程式編輯器），這件事跟你有關嗎？答案是：只有在 2026-10-29 太平洋時間凌晨 2:27 至下午 1:35 之間安裝或更新過 Claude Code（Anthropic——Claude 背後的 AI 公司——開發的 AI 程式工具）套件的人才需要擔心。但最多 5,000 人可能在那 11 小時裡受到影響，這是 Cursor 官方安全公告的上限估算，不是確認受害人數。

在課程裡帶學員討論 AI 工具安裝習慣時，我會問一個標準問題：「你在安裝這個工具之前，有沒有去原廠版本紀錄頁面比對版號？」大多數學員的答案是沒有。Cursor 後門這起事件，恰好把這個習慣的價值測出來了——去比版號的人，有機會在安裝前就察覺 2.1.313 不是 Anthropic 官方發布的版本。

Cursor 後門怎麼查？

讀者打開這篇多半只有一個問題：「我有沒有中？」下面 4 步可在幾分鐘內確認。

1. 確認目前版本：打開 Cursor，進入擴充套件（軟體擴充工具）管理介面，找到 Claude Code 套件，確認版本號是否為 2.1.313。若不是，且安裝時間不在上述時段窗口，風險極低。進一步可去 Anthropic 在 GitHub（全球最大程式碼共享平台）上的 Claude Code 版本紀錄頁面，比對官方目前的正式版本。

2. 檢查 SSH 授權金鑰清單：SSH 是安全遠端連線協議，~/.ssh/authorized_keys 是記錄「誰可以不用密碼就連進你電腦」的授權名單。正常情況下這個檔案只應包含你自己加入或公司 IT 授權的公鑰。任何來源不明的條目都應立即移除。

3. 稽核近期異常外連紀錄：macOS 使用者可在終端機（電腦的命令列介面）輸入 lsof -i | grep ssh；Linux 使用者輸入 ss -tnp | grep ssh。若發現有不明 SSH 對外連線，立即中斷並執行步驟 4。

4. 輪換相關憑證：若步驟 2 或 3 發現異常，立即更換 GitHub token（GitHub 帳號存取金鑰）以及其他 API 金鑰（API 是連接外部服務的程式通行碼，API 金鑰是通行憑證）。

以上步驟整合自資安研究機構 OX Security（AppSec，應用程式安全檢測平台）技術分析（2026-10-30）與 Cursor 官方安全公告。

為什麼官方市集也會中招

很多人的直覺是：「從官方市集裝的不是比較安全嗎？」這個直覺本身沒有錯，但有一個邊界：官方市集驗證的是身份，不是內容。

資安研究機構 Lmntrix 的研究指出：IDE（整合開發環境，即工程師寫程式的工具）擴充套件市集的「已驗證」標記，只確認發布者擁有某個網域，不驗套件的程式碼有沒有被動過手腳。

另一個結構性因素：Cursor 市集底層用的是 Open VSX Registry（VS Code 擴充套件的開源替代市集），與微軟官方 VS Code Marketplace（微軟旗下程式編輯器 VS Code 的官方套件商店）的審核機制不同。科技媒體 Ars Technica 報導指出，Open VSX 的即時偵測資源相對有限。雲端安全聯盟 CSA 研究對比 2026 年 5 月 Nx Console 供應鏈攻擊案（供應鏈攻擊 = 從開發工具上游環節滲入的攻擊方式）：相同類型惡意套件在微軟市集 11 分鐘內下架，在 Open VSX 生態要 33 分鐘，而 Cursor 這次是 11 小時，差距超過 60 倍。

科技研究顧問公司 Gartner 預測，到 2026 年有 60% 的組織將遭遇軟體供應鏈攻擊（對比 2021 年的 15%）。軟體安全研究機構 Black Duck 2026 年對 831 名工程師的調查顯示，97% 積極使用 AI 程式設計工具，但僅 30% 的組織實施正式 AI 工具監管政策。個人層級的版本比對習慣，是在組織治理空窗期自己能做的第一步。

安裝前面試：哪層擋住了

把 Cursor 後門事件當壓力測試，逐層檢驗課程單元 05（AI 技能樹）教的「安裝前面試」框架。

這個框架的起點是一個問題：你在安裝工具之前，有沒有像面試求職者一樣問過它三件事——發布者是誰、版號跟官方一致嗎、它申請的權限跟它說要做的事對得上嗎？學員最常跳過的是第二步。這次事件的意義在於：有去比版號的人，有機會在安裝前就察覺 2.1.313 非官方版本。

資安研究報告 Rescana 說明，本次是「trojanized（植入型）」攻擊：攻擊者把惡意程式碼注入原版套件，外觀與正版高度相似。課程單元 20（Agent 實戰技巧 Plugin）的核心原則——「Plugin（軟體擴充工具）拿到的是你 AI 助理的工作權限，來源可信不是潔癖是底線」——在本次事件裡仍然成立，只是「來源可信」的判定標準需要從「發布者名稱符合」升級為「版號 + 原廠記錄可核實」。

安全責任誰來扛？

兩條反方觀點值得認真看待，各有其道理，也各有邊界。

問題在市集架構，不在使用者習慣

資安研究機構 Lmntrix 研究、CSA 研究的觀點：把安全責任推給使用者去「驗版號」是誤導，因為當市集通路本身被突破時，這些步驟全部無效。真正需要修的是市集的套件簽名驗證（套件簽名 = 每個程式檔案的數位指紋，綁定發布者憑證），而不是個別使用者的行為習慣。

我對這個觀點是條件性同意：市集審核確實有結構性弱點，這是事實。但「問題在平台架構」不代表「使用者不需要任何自己的防線」。截至 2026-10-31，Cursor 尚未公布市集審查流程的架構性改進說明，Open VSX Registry 本身的事件後修補狀態也尚無公開聲明。在結構性修復到位之前，使用者端的主動版本比對是你此刻唯一能控制的額外保護層——你的流程紀律只能管到你自己能控制的那一層，管不到市集架構本身。

11 小時算快還是算慢？

與同類攻擊對比：

• 微軟 VS Code Marketplace：Nx Console 攻擊案，11 分鐘下架（CSA 研究，2026 年 5 月）
• Open VSX 生態：同案，33 分鐘
• Cursor 這次：約 11 小時

我的立場是條件性同意偏慢：11 小時跟 11 分鐘相比差了 60 倍以上。主要原因在於 Open VSX 基底市集的即時偵測資源比微軟主流市集薄，不一定完全歸責 Cursor 個別團隊。但對你的影響是一樣的：使用者在那 11 小時裡沒有得到來自市集的主動保護。如果你依賴的工具走 Open VSX 生態，「市集來得及反應、惡意套件很快就下架」這個假設需要重新評估。

調整後的安裝習慣

從這次事件提取一個具體的行為調整：每次安裝或更新 AI 工具擴充套件時，多做一步——去官方版本紀錄頁面確認版號一致，並對比近期 commit 紀錄（commit = 每次程式碼正式更新的提交紀錄）有無對應的正式發布說明。微版本差異（如 2.1.312 → 2.1.313）尤其要警覺，這次的惡意版本就是靠微版號差異混入的。

這不是要你不裝工具，而是把「安裝前面試」的步驟升級：從「看發布者名稱」升級為「比對版號 + 核實原廠發布記錄」。

已證實事項：惡意版本存在、曝露窗口約 11 小時、Cursor 估計最多 5,000 名使用者受影響（上限估算，非確認受害人數）、攻擊伺服器已下線。未確認事項：攻擊者是否在伺服器下線前實際存取了任何使用者機器（目前無官方數據）、攻擊者身份與入侵市集的具體手法、Cursor 是否已完成市集架構性改進。

帶走的判斷框架

一句方法論：「安裝套件的信任基礎，從『發布者名稱符合』升級為『版號一致 + 原廠記錄可查』。」

三個自我檢查問題：

1. 我上次安裝或更新 AI 工具擴充套件時，有沒有去官方版本紀錄頁面核實版號？
2. 我的 ~/.ssh/authorized_keys 清單上，我認得每一個條目的來源嗎？
3. 當我判斷某個工具「來源可信」時，依據的是「它在官方市集上架」，還是「版號跟原廠發布記錄一致」？

常見問題

• Cursor 後門事件是怎麼回事？ 2026-10-29，Cursor（AI 程式編輯器）自維護的套件市集出現冒用 Anthropic 名稱的惡意 Claude Code 套件（版本 2.1.313），在架約 11 小時後被下架，Cursor 估計最多 5,000 名使用者受影響（上限估算，非確認受害人數）。
• 我怎麼確認有沒有裝到惡意版本？ 確認目前安裝的 Claude Code 版本號是否為 2.1.313，且安裝時間是否在 2026-10-29 太平洋時間 2:27 AM 至 1:35 PM 之間。兩者都符合才需要繼續執行自查步驟 2-4。
• SSH 金鑰被植入了怎麼清除？ 進入 ~/.ssh/authorized_keys，移除任何來源不明的條目，然後輪換相關憑證（GitHub token、API 金鑰等）。攻擊伺服器已下線，但已植入的金鑰需手動清除。
• Anthropic 官方的 Claude Code 有受影響嗎？ 沒有。本次是 Cursor 自維護市集上的冒名擴充套件，不是 Anthropic 官方的 Claude Code 產品本身被入侵，Anthropic 的官方發布管道完全未受影響。
• 以後裝 AI 工具擴充套件怎麼確認安全？ 多做一步：去官方版本紀錄頁面比對版號。微版本差異（如 x.y.z → x.y.z+1）尤其要注意，這次就是靠微版號差異混入的。
• Cursor 之後有做什麼架構性改善嗎？ 截至 2026-10-31，Cursor 尚未公布市集審查流程的架構性改進說明。Open VSX Registry 本身的修補狀態也尚無公開聲明。