2026 年 10 月 30 日，資安公司 Phorion 公布一起供應鏈事件。官方 Claude Code for VS Code 擴充的 2.1.313 版本，在 Cursor Marketplace 上被替換為含後門的組建，模組載入時即寫入攻擊者持有的 Ed25519 公鑰，並建立反向 SSH 通道。
植入程式同時在 macOS、Linux 與 Windows 留下開機持續執行機制，並回傳主機名稱、Git 電郵與環境變數名稱清單。Cursor 已下架該版本，NPM 與 VS Code 市集同步移除同號建置。
這次事件的實際情況是什麼？
官方 Claude Code 擴充 2.1.313 在 Cursor 市集被換成含後門版本。編輯器一載入即寫入公鑰並建立反向 SSH 通道，使用者不需任何互動。
受影響的檔案是擴充目錄內的 extension.js。攻擊者在壓縮後的組建最前面插入一段立即執行函式，其餘內容維持原樣，包含 Claude Code 與 VS Code 的相關字串、正常的 activate 與 deactivate 匯出，以及介面邏輯。
這種做法讓檔案在靜態比對時不易被察覺。注入的前綴引入 Node.js 內建的 child_process、fs、os、path、http 與 crypto 模組，於 Node 載入檔案的瞬間執行，時間點早於擴充本身的 activate 回呼。
使用者不需要點擊任何按鈕，也不需要開啟 Claude Code 面板。只要編輯器載入該擴充，植入程式就會啟動。對於每天開著 IDE 的開發者而言，這個條件幾乎自動成立。
後門如何繞過正常安裝流程？
攻擊者更換的是市集上的組建內容，而非簽章或帳號。擴充以 IDE 與使用者權限執行，載入即取得本機檔案、原始碼與開發工具的完整存取權，因此不需提權漏洞也能完成植入。
Cursor Marketplace 提供的擴充以編輯器權限執行。一旦模組載入，後門即取得使用者可存取的全部檔案，包含原始碼、設定檔與憑證。這個權限模型本身沒有問題，問題在於市集對組建內容的驗證深度。
事件中的樣本沒有使用任何提權漏洞。第一階段僅嘗試在既有權限內完成設定，遇到需要管理員權限的步驟時，腳本並未提供繞過手段，而是直接失敗。
這意味著攻擊的假設相當務實：多數開發機器已開啟遠端登入，或使用者具備免密碼的 sudo 設定。只要其中一項成立，後門就能取得完整的互動式存取能力。
攻擊者用哪三組金鑰建立存取？
一組公鑰寫入授權檔供攻擊者登入，一組私鑰連向通道伺服器，第三組由開機腳本重建。註解分別是 svc-telemetry 與 svc-telemetry-tun。
第一階段確保 ~/.ssh 目錄存在，並把攻擊者控制的 Ed25519 公鑰附加到 authorized_keys，目錄權限設為 0700，檔案設為 0600。公鑰註解為 svc-telemetry，與系統服務的命名風格相近。
寫入前的檢查只看註解字串是否已存在，而非比對金鑰指紋。這個細節影響調查方式：單憑註解搜尋可能漏掉被改寫過註解的樣本，指紋比對較可靠。
第二階段解碼另一組內嵌的 Ed25519 私鑰，註解為 svc-telemetry-tun，寫入系統暫存目錄，檔名以 .stk_ 開頭，後接主機名稱與家目錄路徑的 MD5 前十字元。這組金鑰用於讓受害主機主動連向外部伺服器。
第三階段把同一組私鑰嵌入持續執行腳本，開機時重新寫出。金鑰因此能在暫存目錄被清理後自動復原，清理流程必須同時處理設定檔與腳本。
反向通道如何運作？
腳本以 tunnel 身分連向該 IP 的 22 埠，用遠端埠轉發語法要求動態分配埠位，再把流量轉回本機 SSH。通道以 -N 執行，不開互動 shell。
指令使用遠端埠轉發，把 0 作為埠號傳給伺服器，由對方動態分配監聽埠。任何連到該埠的流量，都會經既有通道轉回受害主機的 localhost:22。
攻擊者其後另開一段連線，用第一階段植入的公鑰登入本機 SSH 服務。這種設計把命令與控制邏輯外移到 SSH 本身，JavaScript 端不需要實作任何自訂通訊協定。
連線參數刻意降低痕跡：關閉主機金鑰檢查、忽略 known_hosts、啟用 BatchMode 與 IdentitiesOnly，並設定 30 秒保活與轉發失敗即退出。若系統已安裝 autossh 則優先使用，否則退回標準 ssh。
外層再包一層脫離終端的重試迴圈，每 60 秒重連一次，並以 pgrep 避免產生重複通道。因為迴圈已脫離終端，關閉 IDE 不會中斷連線。
開機持續執行靠什麼機制？
三平台各用原生機制：Linux 寫入開機排程項目，macOS 建使用者層 LaunchAgent，Windows 試以 SYSTEM 身分建排程，失敗改放啟動腳本。
Linux 與 macOS 都會產生 ~/.config/.smt 與 ~/.config/.smtk 兩個檔案。前者是重連腳本，內含通道私鑰，執行時先把金鑰寫回 .smtk 再進入迴圈。
macOS 額外建立 ~/Library/LaunchAgents/com.apple.sysmond.plist，標籤模仿系統守護程序，並設定 RunAtLoad 與 KeepAlive 為 true，透過 launchctl 載入。由於置於使用者層而非系統層，不需要管理員權限即可生效。
Linux 版本在 crontab 檢查上存在缺陷。重複執行時可能覆寫使用者原有的排程項目，對受感染主機造成額外的工作遺失風險。
Windows 版本先嘗試建立名為 SysMon 的排程工作並要求 SYSTEM 權限，失敗則把 sysmon.cmd 放入使用者的啟動資料夾。該路徑的 PowerShell 呼叫經過硬編碼 /bin/sh 的輔助函式，在標準 Windows 環境無法運作。
為何 macOS 上的啟用邏輯會失效？
腳本以一般權限查詢遠端登入狀態，該指令權限不足時輸出錯誤訊息但回傳成功碼，輸出不含 Off，判斷不成立，啟用步驟被跳過。
systemsetup -getremotelogin 在缺少管理員權限時，會把「需要管理員權限」的提示輸出到標準輸出，並以狀態碼 0 結束。腳本以正規表示式檢查輸出是否包含 Off，結果為 false。
於是 sudo -n systemsetup -setremotelogin on 這一步從未執行。對一台原本未開啟遠端登入的 Mac 而言，攻擊者雖然仍能建立對外通道，但回程流量會在 localhost:22 遇到關閉的埠。
這個缺陷降低了 macOS 的實際風險，卻不能當作防線。若使用者原本已開啟遠端登入，或日後自行開啟，後門就處於可用狀態，公鑰與持續執行機制早已就位。
主機有哪些跡象可以判斷是否中招？
跡象包括 IDE 輔助程序寫入授權檔、非 Apple 程序建立 com.apple.* 啟動項、隱藏目錄出現 .smt，以及 SSH 帶遠端埠轉發連向外部 IP。
檔案層面的訊號最直接。由於寫入動作由 Node 的 fs.appendFileSync 完成，只監控 echo 或 tee 等 shell 指令的規則不會觸發，必須依賴檔案修改事件，觀察 Code Helper、Cursor Helper 等程序是否動到 SSH 授權檔。
程序與網路層面，可留意帶有遠端埠轉發參數的 ssh 或 autossh，其身分檔來自 /tmp/.stk_* 或 ~/.config/.smtk，並連向 134.209.82.225 的 22 埠。
外傳訊號同樣明顯。樣本以明文 HTTP 對 134.209.82.225:8099 的 /beacon 路徑發出 POST，內容為 JSON。同一份資料也會送往 127.0.0.1:8099，來源文章未能解釋這個設計。
若曾在 SSH 日誌看到來源為 127.0.0.1 或 ::1、並以 svc-telemetry 金鑰完成的登入，代表通道已被實際使用，而非僅建立。
受影響的機器應該如何清理？
卸載擴充不足以清除後門。須終止重試迴圈與 SSH 程序、刪除持續執行項目、移除 .smt 與 .smtk、清走授權檔公鑰，並輪換可能外洩的憑證。
清理順序建議由執行中程序開始。先終止 /bin/sh 重試迴圈與任何連向 134.209.82.225 的 ssh 或 autossh 程序，否則刪除的檔案會被重新寫回。
接着處理持續執行機制。macOS 需卸載並刪除 com.apple.sysmond.plist，Linux 需清除 @reboot 的 crontab 項目，Windows 需移除 SysMon 排程工作與啟動資料夾腳本。之後刪除 ~/.config/.smt、~/.config/.smtk 與 /tmp/.stk_*。
金鑰與狀態的清理不可省略。從 authorized_keys 移除 svc-telemetry 公鑰，並確認遠端登入未被意外開啟。
若主機曾開啟 SSH，或日誌出現可疑登入，應輪換該使用者可存取的全部憑證與權杖，特別是名稱符合 KEY、TOKEN、SECRET、PASS、AWS、GCP 的環境變數所對應的服務。
這次事件反映供應鏈的什麼問題？
擴充市集以簽章與版本號作為信任基礎，但組建內容在發佈後仍可能被替換。當開發工具權限等同使用者本人，市集審查的深度就決定單一檔案被改動後的影響範圍。
樣本保留原有匯出函式與介面字串，壓縮後的程式碼在主觀檢視下與正常版本差異有限。這種改動方式利用的是信任鏈末端的空白：開發者相信市集上的版本與官方發佈一致。
同一個版本號同時出現在 Cursor Marketplace、NPM 與 VS Code 市集，說明污染可能發生在建置或發佈環節，而非單一平台的審查疏漏。
對開發者而言，可行的降低風險做法包括延後採用新版本、比對檔案雜湊、限制 IDE 擴充的執行權限，以及對開發機器套用端點偵測。這些措施都無法取代市集端的驗證，但能縮短從發佈到發現的時間。
常見問題有哪些？
以下整理版本範圍、平台差異、卸載是否足夠，以及日常防護重點，協助判斷手上的開發環境是否需要進一步檢查與處理。
出處連結有哪些？
本文資訊整理自 Phorion 於 2026 年 10 月 30 日發佈的技術分析，內含完整感染鏈、檢測指標與修復建議，原始文章附有雜湊值與網路指標清單。
原始分析：https://phorion.io/blog/offical-claude-code-vsx-compromise/
樣本 SHA-256：ecb58cb29078d9646ad1dcdbe51526f2d9cfea06be5fb2ab183e8ecc3ab6bf15
總結：開發者應如何調整擴充安裝習慣？
擴充的權限等同使用者本人，任何版本更新都應視為程式碼變更。延後採用、核對雜湊、監控 SSH 授權檔與開機項目，比事後清理更能控制這類供應鏈事件的影響。
這次事件的技術含量不算高，樣本甚至帶有多處實作缺陷，包括 macOS 的權限判斷與 Windows 的 shell 路徑。真正值得留意的是權限邊界：一個開發者每天載入數十次的工具，能在無提示的情況下改寫 SSH 設定。
對個人開發者而言，最有效的動作是把版本更新與檔案雜湊納入日常檢查，並定期檢視 authorized_keys 與開機項目。對團隊而言，端點層的檔案修改監控比市集評分更可靠。
