5000 名開發者真的被黑了嗎？Cursor 插件投毒事件目前到底產生了什麼影響？

作者注：本文拆解 Cursor 插件投毒事件裏“最多 5000 人受影響”的真實含義，梳理攻擊鏈、已覈實案例、API Key 風險邊界和自查步驟，幫你分清哪些說法有證據，哪些屬於誇大。

2026 年 10 月 29 日，Cursor 擴展市場出現了被篡改的 Claude Code 擴展。隨後幾天，“5000 名開發者被黑”“Claude API Key 大規模泄露”之類的標題開始流傳。實際情況是：5000 是 Cursor 官方給出的潛在受影響用戶上限，並不是 5000 起已確認的成功入侵。

這不是在替誰淡化風險。Cursor 官方公告、微軟安全研究團隊、Phorion、Expel 等多家機構都已確認事件真實發生，也已經在客戶設備上觀察到惡意活動。本文按“分發、執行、寫入、可利用、實際入侵、數據損失”六個層級，逐層說明哪些事實已經覈實，哪些數字目前沒有公開。

核心價值：讀完本文，你能判斷 Cursor 插件投毒對自己和團隊的實際影響，並照着官方建議的步驟完成自查與憑證輪換。

Cursor 插件投毒事件核心信息速覽

先看幾項已經覈實的基礎事實。理解這起事件的關鍵在於邊界：它是開發工具的軟件供應鏈攻擊，不是 Claude 模型被攻破，也不是 Anthropic 內部系統失守。

Anthropic 表示這些惡意構建不是它開發或發佈的，事件也不涉及其內部系統或員工電腦。攻擊者是怎麼拿到向 Cursor 市場發佈構建的權限的，截至 11 月 2 日仍沒有公開的調查結論。

Cursor 插件投毒關鍵時間線

這起事件裏有兩個時間概念容易混在一起。一個是市場可下載惡意包的時間窗口，另一個是已安裝設備上惡意代碼實際運行的時間。後者可以比前者晚很多，插件下架並不代表本地已經安全。

最初也有報道稱是 Open VSX 被攻擊。OpenSourceMalware 後來更正了這一說法，Socket 檢查 Open VSX 註冊表記錄後也沒有找到對應惡意版本。目前能確認的被攻擊渠道只有 Cursor Marketplace。

Cursor 插件投毒如何工作：從 66 行加載器到反向 SSH 隧道

據 Phorion 和 OpenSourceMalware 分析，攻擊者在正常擴展的 extension.js 開頭插入了約 66 行惡意 JavaScript 加載器，位置在正常業務代碼之前。擴展模塊一加載就會觸發，用戶不用給 Claude 發消息，也不用授權任何編程任務。Claude Code 的界面和功能照常可用，部分錯誤還被靜默處理，用戶很難察覺。

整條攻擊鏈可以歸納爲以下六步：

1. 收集主機信息：主機名、用戶名、操作系統與 CPU 架構、主目錄、工作目錄、Git 全局郵箱、公網 IP 等。
2. 植入 SSH 授權密鑰：向用戶的 authorized_keys 寫入攻擊者控制的公鑰，標記爲 svc-telemetry。
3. 嘗試啓用 SSH 服務：設備開放 SSH 登錄的話，攻擊者就可能用植入的密鑰登錄。
4. 建立反向 SSH 隧道：由受害設備主動連接攻擊者服務器（TCP 22），再把連接轉發回本機 SSH 服務，以此繞過部分入站限制。
5. 部署持久化：在 macOS、Windows 上設置登錄後自動重連，Linux 上通過 crontab @reboot，這樣後門不依賴擴展本身也能運行。連接失敗時大約每 60 秒重試一次。
6. 回報執行狀態：通過 TCP 8099 端口的 HTTP Beacon 向服務器上報主機信息和各步驟執行結果。

爲什麼 Cursor 插件投毒不是提示詞注入

很多人看到“Claude Code 出事”，第一反應是模型被惡意 Prompt 操縱了。這次不是。它是典型的擴展代碼執行攻擊，惡意邏輯跟模型輸出完全無關，換成任何一個被篡改的 IDE 插件，原理都一樣。所以討論 Claude 模型本身的安全性，對這起事件沒有意義。真正暴露出來的問題是：開發工具的插件分發渠道一旦被冒用，信任鏈就會斷掉。

惡意代碼的兩個實現缺陷

這次攻擊的危險性因爲代碼寫錯而打了折扣。macOS 上，惡意代碼查詢 Remote Login 狀態時沒有用管理員權限，系統返回的是權限錯誤，不是“已關閉”。而程序只在明確識別到“已關閉”時纔會去開啓 SSH，所以在很多原本沒開 SSH 的 Mac 上，這一步會失敗。Windows 上，它安裝 OpenSSH Server 時錯誤地調用了 Unix 風格的 /bin/sh，標準 Windows 環境裏沒有這個路徑。

不過，缺陷不等於失效。惡意代碼仍然能寫入公鑰、生成持久化腳本、發起網絡連接、上報主機信息。原本就開着 SSH 的設備風險會高很多。Phorion 聯合創始人 Calum Hall 接受 WIRED 採訪時也說，如果實現正確，這本可能成爲非常危險的攻擊入口。

5000 名開發者被黑了嗎：Cursor 插件投毒影響的 6 個層級

“5000”的原文出自 Cursor 10 月 29 日的初版公告：“At most 5,000 users were affected”，意思是最多 5000 名用戶受到影響。這是官方自報的上限，不是安全機構獨立確認的入侵數。初版公告只提到 2.1.313，更新後補充了 2.1.312，但官方沒有公開兩個版本各自對應多少用戶，也沒有給出修訂後的完整人數拆分。

把影響拆成六層看，哪些已經證實、哪些只是推測，就比較清楚了：

圖中左右兩邊的差距，就是新聞標題和證據之間的差距。越往漏斗下層，公開證據越少。“5000 臺電腦被完全控制”“5000 人的 API Key 被盜”這兩種說法，目前都找不到證據支持。

Expel 4 起實案說明了什麼

Expel 在 10 月 29 日至 30 日處理了 4 起相關客戶事件，涉及 4 家客戶，每起各 1 臺 Mac。其中 3 臺用的是 CrowdStrike Falcon，1 臺用的是 Microsoft Defender for Endpoint。4 起事件都有連向攻擊者服務器 IP 的網絡連接。這說明事件已經不只停留在實驗室代碼分析階段。

最值得注意的是那起延遲執行的案例。用戶在北京時間 10 月 30 日 12:44 登錄 Mac 並啓動 Cursor，一分鐘後出現惡意活動，到 22:29 仍有連向攻擊者 IP 的連接，前後將近 10 小時。這時市場早已下架惡意包，比較合理的解釋是安裝包在暴露期內已經下載好，等用戶重新打開 Cursor 才被觸發。

這組數據有明確的邊界：4 起不代表全球只有 4 臺設備中招，不能用 4 除以 5000 去算感染率，檢測到 SSH 隧道也不等於攻擊者已經登錄成功。Phorion 也在客戶 Mac 上發現過樣本，但它和 Expel 的案例是否有重合並不清楚，不能簡單相加。Expel 還發現一臺機器上有惡意隧道進程，卻沒有 svc-telemetry 公鑰標記，可見只搜一個標記很容易漏報。

Cursor 插件投毒中的 API Key 風險邊界

惡意代碼最多會篩選 40 個名稱裏含 KEY、TOKEN、SECRET、PASS、AWS、GCP 的環境變量。比如機器上設置了 OPENAI_API_KEY，攻擊者就能知道這臺機器在用相應的服務。但研究人員確認，初始上報的只是變量名稱，不是變量的值。

所以準確的說法是：攻擊代碼能識別敏感配置的類別。如果後門真的被利用，攻擊者有可能進一步讀取本地憑證和源代碼。至於實際有多少 API Key 被竊取，目前沒有任何公開數據。“已竊取所有用戶 API Key”屬於把能力等同於結果。不過風險邊界不清楚，恰恰說明應該把憑證輪換當成預防措施來做。

Cursor 插件投毒影響分析

對開發者的影響

• 卸載插件不夠：官方明確提醒，只卸載或升級到 2.1.314，不一定能清除已經寫入的 SSH 公鑰、啓動項和後臺腳本。
• 下架後仍可能觸發：Expel 的延遲案例說明，“下架後纔打開 Cursor”的用戶同樣需要自查。
• SSH 常開的機器風險更高：開發機爲了遠程調試常開 Remote Login，正好避開了惡意代碼的實現缺陷。
• 憑證暴露面被摸底：哪怕後門沒有成功利用，攻擊者也可能已經知道你用了哪些雲服務和 API。

對團隊與行業的影響

• 插件分發成爲新的攻擊面：同一擴展在不同市場的版本可能來源不同，判斷時要結合安裝來源和文件哈希，不能只看版本號。
• AI 編程工具獲得的終端權限需要重新評估：IDE 插件一般以用戶權限運行，能讀寫主目錄、發起網絡連接，企業應該把它們納入終端管控。
• 事件響應需要覆蓋憑證生命週期：受影響設備能訪問的倉庫、API Key、雲憑證、會話令牌都應該評估。項目用到的 Key 越分散，輪換成本越高。

Cursor 插件投毒自查與憑證輪換實操

首先建議使用 Cursor 官方公告裏提供的 macOS 與 Windows 檢查和修復腳本。下面的指標和命令用於輔助理解與排查，不能替代官方腳本和日誌調查。

第一步：本機快速排查（macOS 示例）

# 1. 檢查授權公鑰中是否有攻擊者標記（注意：沒找到不代表安全，可能漏報）
grep -n "svc-telemetry" ~/.ssh/authorized_keys

# 2. 檢查持久化文件與啓動項
ls -la ~/.config/.smt ~/.config/.smtk ~/Library/LaunchAgents/com.apple.sysmond.plist 2>/dev/null

# 3. 檢查是否存在與惡意服務器的連接
lsof -nP -i | grep "134.209.82.225"

# 4. 確認 Remote Login 狀態（需要管理員權限）
sudo systemsetup -getremotelogin

Windows 用戶可以用 schtasks /query /tn SysMon 檢查計劃任務，再到啓動目錄裏找 sysmon.cmd。只要任何一項命中，就應該保留證據、隔離設備，然後按官方腳本清理。設備可信狀態無法恢復的話，要考慮重裝系統，並在另一臺可信設備上輪換憑證。

第二步：盤點暴露的憑證變量名

下面的腳本用和惡意代碼相同的關鍵詞篩選環境變量，只打印名稱、不打印值，可以幫你列出需要輪換的清單。輪換完成後，再用一次最簡單的 API 調用確認新 Key 能用：

import os, re, openai

# 與惡意代碼相同的關鍵詞，列出可能被“摸底”的變量名
pattern = re.compile(r"KEY|TOKEN|SECRET|PASS|AWS|GCP")
print([k for k in os.environ if pattern.search(k.upper())])

# 在可信設備上輪換後，用新 Key 驗證調用
client = openai.OpenAI(
    api_key=os.environ["NEW_API_KEY"],
    base_url="https://api.apiyi.com/v1"  # API易 OpenAI 兼容接口
)
r = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "ping"}]
)
print(r.choices[0].message.content)

import os
import re
import openai
from typing import List

KEYWORDS = re.compile(r"KEY|TOKEN|SECRET|PASS|AWS|GCP")

def list_sensitive_env_names(limit: int = 40) -> List[str]:
    """只返回疑似憑證的環境變量名稱，絕不輸出值。
    limit 與惡意代碼的篩選上限保持一致，用於還原攻擊者可能看到的視圖。"""
    names = [k for k in os.environ if KEYWORDS.search(k.upper())]
    return sorted(names)[:limit]

def verify_new_key(model: str = "gpt-4o-mini") -> bool:
    """輪換後驗證新 Key 是否可正常調用"""
    client = openai.OpenAI(
        api_key=os.environ.get("NEW_API_KEY", ""),
        base_url="https://api.apiyi.com/v1"
    )
    try:
        resp = client.chat.completions.create(
            model=model,
            messages=[{"role": "user", "content": "ping"}],
            max_tokens=10
        )
        return bool(resp.choices[0].message.content)
    except Exception as e:
        print(f"驗證失敗: {e}")
        return False

if __name__ == "__main__":
    print("可能暴露給攻擊者的變量名：")
    for name in list_sensitive_env_names():
        print("  -", name)
    print("新 Key 驗證結果：", verify_new_key())

第三步：按優先級輪換憑證

🎯 技術建議：如果項目同時直連 OpenAI、Claude、Gemini 等多家平臺，事發後就得分別登錄多個後臺吊銷、重建 Key。官方推薦把模型調用統一收斂到 API易 apiyi.com，一個 Key 覆蓋多家主流模型，接口兼容 OpenAI，輪換時改一處配置就夠了，也便於集中查看用量、發現異常消費。

常見問題 FAQ

Cursor 插件投毒核心要點 Key Takeaways

• 事件性質：Cursor 市場分發了篡改的擴展，屬於供應鏈攻擊，不是 Claude 模型漏洞
• 5000 的含義：這是官方給出的潛在影響上限，不是已確認的入侵數量
• 已證實的部分：獨立機構在真實 Mac 上觀察到惡意活動和外聯
• 未公佈的部分：成功遠程登錄人數、被盜 Key 數量、經濟損失
• 關鍵風險：下架後仍可能觸發，卸載插件不能保證清除後門
• 處置方式：運行官方腳本，在可信設備上輪換憑證，藉助 API易 apiyi.com 收斂 Key 數量

總結

Cursor 插件投毒事件的核心要點：

1. 區分標題和證據：“最多 5000 人受影響”和“5000 人被黑”差了好幾個層級，當前公開證據停在“已有真實執行案例”這一層。
2. 攻擊確實存在，但打了折扣：惡意代碼具備後門和持久化能力，macOS 與 Windows 上的實現缺陷降低了遠程登錄的成功率。
3. 自查不能只做一項：要結合安裝來源、文件哈希、進程、網絡連接和啓動項，只搜 svc-telemetry 可能漏報。

如果你在 10 月 29 日至 30 日期間通過 Cursor 市場使用過 Claude Code 擴展，請先按官方指引自查，再按優先級輪換憑證。模型 API 這部分，可以借這次機會把分散的 Key 統一到 API易 apiyi.com，下次需要應急輪換時會省事很多。

📚 參考資料

1. Cursor 官方安全公告：事件時間、版本、惡意文件哈希與清理腳本
2. 鏈接：cursor.com/blog/claude-code-extension-security-notice

3. 說明：自查時首先參考這份公告，包含 macOS 與 Windows 修復腳本

4. Microsoft Security Research：惡意 Claude Code 擴展攻擊鏈分析

5. 鏈接：microsoft.com/en-us/security/blog/2026/10/30/inside-malicious-claude-code-branded-cursor-extension-persistent-ssh-backdoor/

6. 說明：確認供應鏈邊界、SSH 機制與持久化細節

7. Phorion：Official Claude Code Extension Compromise

8. 鏈接：phorion.io/blog/offical-claude-code-vsx-compromise/

9. 說明：66 行加載器、平臺差異與代碼缺陷的技術細節

10. Expel：Fake Claude Code extensions in Cursor

11. 鏈接：expel.com/blog/blog-fake-claude-code-extension-cursor-ssh-backdoor/

12. 說明：4 起真實客戶事件與延遲執行案例

13. Socket：Cursor Removes Malicious Claude Code Extension

14. 鏈接：socket.dev/blog/claude-code-extension-compromise
15. 說明：Open VSX 與 npm 記錄覈查，糾正早期誤報

作者：APIYI 技術團隊
技術交流：歡迎在 API易 apiyi.com 首頁聯繫我們，更多接入資料可訪問 docs.apiyi.com 文檔中心

延伸閱讀

• Claude Code 擴展被投毒：2.1.313 後門，5 步自查與清除:10 月 29 日，Cursor Marketplace 上的官方 Claude Code 擴展 2.1.312、2.1.313 被換成帶 SSH 後門的構建，最多 5,000 名用戶暴露。本文用 5 步講清如何自查 svc-telemetry 公鑰、清除 LaunchAgent 與計劃任務等持久化、升級到 2.1.314 及以上版本，並完成 GitHub、雲憑據和 API易 Key 輪換，幫你把這次事件真正收尾。
• Claude Max 改名 Ultra，5 小時限制取消了嗎？3 個變化先看清:Claude Max 20x 改名 Ultra、Max 5x 改名 Max，價格不變；已認證 Ultra 賬戶取消 5 小時限制，周限額不變。本文用對照表、3 步自查和算賬幫你判斷要不要換檔。