十二小時、五千台機器：一個不屬於 Anthropic 的 Claude Code 擴充套件

上週四的某個時刻，躺在 Cursor 擴充套件商店裡的那份 Claude Code 擴充套件，不再是它自稱的那個東西。兩個版本——2.1.312 和 2.1.313——夾帶了持續性的 SSH 後門。它就這樣掛在架上將近十二個小時。Cursor 自己統計的受影響開發者人數是「最多 5,000 人」。

細節來自一天之內陸續刊出的一批資安報導：Step Security、Sophos、BleepingComputer、微軟的安全部落格，以及把時間軸整理得最精確的 Ars Technica。根據這些報導，被動過手腳的擴充套件做了後門該做的事——開了一條重開機後依然存在的入口，在這個案例裡是走 SSH。The Verge 的整理則提到，payload 會蒐集主機名稱、使用者名稱與 IP 位址。

這是短版。長版要談的是：擴充套件商店究竟是什麼東西，以及為什麼這種事早晚會發生。

實際被攻破的是什麼

不是 Anthropic 的伺服器，不是 Claude 模型。是一個散布通路。

Claude Code 同時以命令列工具和編輯器擴充套件的形式發布。Cursor 有自己的擴充套件商店，運作方式跟 VS Code 一樣，而這次出事的項目，掛的招牌是官方 Claude Code 擴充套件。對一個在編輯器裡搜尋「claude code」的開發者來說，這個項目看起來完全正確：名字對、圖示對、說明也對。

安裝時跑起來的卻是動過手腳的版本。報導描述的機制是一個持續性的 SSH 後門——一種讓攻擊者之後可以透過 SSH 登入這台機器的改動，不需要使用者再做任何事。對開發者的筆電來說，這幾乎是最糟的 payload。它不是那種會在活動監視器裡冒出來的挖礦程式，它是一扇安靜的門。

為什麼開發者是理想目標

一台被攻破的開發機，不只代表一台筆電。它代表的是一組觸及範圍異常寬廣的憑證：私有 repo 的原始碼、CI token、雲端金鑰、某人三月就說要清掉卻還躺在 .env 裡的資料庫連線字串、在整個機隊裡互相關聯的 SSH 金鑰。

SSH 後門特別適合這種環境，因為開發機本來就在跑 SSH，本來就有 authorized_keys，也本來就預期會有其他機器連進來。在那個檔案裡多一把新金鑰，不會像一條連向未知 IP 的新對外連線那樣顯眼。

再加上時間點：週四、上班時間、很多團隊正處於發布週期之中。這個窗口不算長，但如果那個項目排在搜尋結果前幾名，十二個小時足以造就幾千次安裝。

大家不太想說出口的那部分

擴充套件商店並不是消費者理解的那種 App Store。它們更接近套件註冊庫。審查流程是有的，但它的方向是在送審當下抓明顯的惡意行為，而不是持續驗證發布者還是原來那個發布者、二進位檔還是原來那個二進位檔。

這不是 Cursor 獨有的失誤。這是每一個允許第三方發布「以完整本機權限執行的程式碼」的生態系的結構性弱點：npm、PyPI、VS Code 擴充套件、瀏覽器擴充套件，以及現在圍繞 AI 編碼工具長出來的那些商店。攻擊面不是模型，是安裝器。

讓這次事件特別受注目的是品牌。一個以知名 AI 產品命名的擴充套件，出現在一個大部分使用者正好在找那個產品的商店裡，是一種很難防的信任捷徑。名字本身完成了社交工程。

事後處理長什麼樣

項目被下架，Cursor 公布了使用者數量。資安廠商公布了入侵指標。根據報導，Anthropic 並不是發布那個惡意版本的一方——Cursor 商店上那份擴充套件，和 Anthropic 自己的發布通路是兩條不同的線。

這個區別對究責很重要，對風險不重要。從開發者的角度來看，「我在編輯器裡的商店安裝了 Claude Code 擴充套件」是一個動作，而它背後那一整條保管鏈是看不見的。

這週該做的事

如果你用 Cursor，或用任何有第三方商店的編輯器，這週很適合做三件無聊的事。

第一，列出你安裝的擴充套件，檢查發布者。不是看名字——看發布者，最好也看安裝來源。任何你不認得的，移除。任何跟你已經從第一方取得的功能重複的，移除。

第二，檢查你開發機上的 ~/.ssh/authorized_keys。你要找的是你不認得的金鑰。在一台只會往外連的筆電上，這個檔案通常是空的、甚至不存在，所以任何意外出現的條目都很容易看出來。

第三，輪替那台機器能碰到的憑證。這是最貴的一步，也是大家會跳過的一步。如果你沒辦法全部換掉，至少換掉最痛的那些：雲端供應商金鑰、套件註冊庫 token，以及任何對正式環境 repo 有寫入權限的東西。

如果是團隊，再加一項：把擴充套件版本釘死，只從審核過的名單安裝，而不是讓個人自行安裝搜尋排名高的東西。這個政策大多數團隊早就對 npm 依賴套用，卻幾乎沒有人套用在編輯器外掛上。

為什麼半天沒人發現

十二小時以絕對時間來說不長，但對一個散布通路來說，是很長的一段生命。在那個窗口裡，這個擴充套件可以安裝，可以安裝就代表可以執行，可以執行就代表每一個在正常上班日按下安裝的開發者都可能暴露。

值得注意的是，偵測來自外部。盯著可疑行為的資安廠商先標記了它，商店本身沒有。這不是在針對 Cursor——這些生態系本來就是這樣運作。註冊庫最佳化的是可用性，不是對每一個託管的產物做持續的行為監控。要即時掃描每個擴充套件的每一次更新，成本高得可怕，而在事情爆掉之前，做這件事的誘因很弱。

復原比偵測快。項目下架、公告發布、指標分享。但順序才是重點：先暴露，後解釋。對那些在窗口期間安裝的人來說，有用的資訊是在關鍵決定之後才送達的。

讓人不舒服的結論

AI 編碼工具這個類別花了兩年在比能力：上下文長度、agent 迴圈、這東西能改多少檔案而不失焦。它幾乎沒有花任何時間在比供應鏈完整性，因為到目前為止，威脅模型是「模型會寫出爛程式碼」，而不是「擴充套件是惡意軟體」。

以過去十年軟體供應鏈攻擊的標準來看，5,000 台機器、十二小時，是一次很小的意外。它同時也是一次預演。下一次會是一個 MCP server，或一個 skill 套件，或某個熱門 agent 會直接點名推薦的外掛。模式一模一樣：一個可信的名字、一個驗證鬆散的通路，以及一個不需要張揚的 payload。

教訓不是「不要用擴充套件」。而是：商店列表上的「官方」兩個字幾乎不代表任何東西，而唯一能規模化的防禦，是用你面對一個從沒聽過的套件、隨手敲下 npm install 時的那種懷疑，來看編輯器外掛。