Elvis Li
Back to all posts
Cybersecurity

11分鐘的夢魘：Nx Console VS Code 擴展遭入侵內幕

#cybersecurity#supply-chain#vscode#nx#github#devops

如果你認為本地編碼環境是一個安全的沙盒，我有一些極其糟糕的消息要告訴你。2026 年 5 月 18 日，開發者社區在殘酷的安全衝擊中醒來。Nx Console，一個擁有超過 220 萬次安裝量的 Visual Studio Code 擴展，在一次複雜的供應鏈攻擊中被劫持。

一個被追蹤為 TeamPCP 的威脅組織成功向 Visual Studio Marketplace 和 Open VSX Registry 發布了一個被投毒的更新 (v18.95.0)。儘管 Nx 的維護者以極快的速度採取了行動——在 11 分鐘 內在 VS Marketplace 上清除並修補了該擴展，在 36 分鐘 內在 Open VSX 上完成了修補——但損害已經造成。一名 GitHub 工程師的工作站自動拉取了該惡意更新，從而建立了一個據點，允許攻擊者滲透並竊取了大約 3800 個內部 GitHub 存儲庫。

我花了過去兩天時間分析該漏洞利用向量。讓我們拆解一下這是如何發生的，重構“孤兒提交 (Orphan Commit)”加載器，研究為什麼您的本地 AI 開發人員密鑰成為新的高價值目標，並討論我推薦的鎖定本地設置的具體策略。

解構妥協鏈條

說實話：這不是一次簡單的排版錯誤搶註 (typosquatting) 或依賴混淆攻擊。惡意行為者破壞了官方發布管道本身。

最初的破壞並非始於 Nx 存儲庫。相反，這是一個級聯鏈條。TeamPCP 之前已經入侵了 TanStack 生態系統中的貢獻者。透過那個切入點，他們竊取了一名開發者的 GitHub CLI OAuth 令牌，該令牌擁有官方 nrwl/nx 存儲庫的寫入權限。

TeamPCP 沒有開啟高度可見的拉取請求或直接推送到 main 分支（這會觸發分支保護警報），而是使用了一種極其巧妙、隱蔽的向量：孤兒提交 (The Orphan Commit)。

                           [ TanStack 生態系統遭入侵 ]
                                        │
                         (GitHub OAuth 令牌被竊取)
                                        │
                                        ▼
                   [ nrwl/nx 存儲庫的寫入權限被利用 ]
                                        │
              (直接在 Git 樹中創建的隱蔽孤兒提交)
                                        │
                                        ▼
           [ 惡意的 Nx Console VS Code 擴展 (v18.95.0) ]
             (預編譯為包含獲取孤兒提交的靜態 URL)
                                        │
                                        ▼
             [ Visual Studio Marketplace / Open VSX 發布 ]
                                        │
                                        ▼
                 [ 開發者機器自動更新 / 執行 ]

什麼是孤兒提交 (Orphan Commit)？

孤兒提交是直接推送到存儲庫對象存儲中的提交，它沒有附加到任何命名的分支、標籤或活動的引用樹上。

因為 Git 是內容尋址的，你可以使用底層的底層 (plumbing) 命令創建並推送提交。它不會出現在 main 分支的提交歷史或活動分支列表中，但該提交在存儲庫的對象存儲中仍然是活動的。任何知道確切提交 SHA 的人都可以訪問代碼，或直接從 GitHub 的原始 CDN 中拉取它：

# 在 Git 中查詢鬆散對象：即使提交被孤立，
# 它也會被存儲，並且可以直接從 GitHub raw 查詢或拉取。
git cat-file -p <orphan_commit_sha>

TeamPCP 用一個簡單的加載器構建了他們的惡意擴展。一旦安裝，它會聯繫官方的 nrwl/nx 存儲庫，並從這個隱藏的孤兒提交中拉取次要有效載荷。對於靜態分析工具和防火牆來說，該網絡請求看起來完全無害：一個官方 Microsoft VS Code 擴展從官方驗證的存儲庫中獲取代碼。

一旦加載到內存中，次要有效載荷就會執行，立即啟動一個本地憑據收集器。

鎖定您的 AI API 機密

傳統上，開發人員憑據竊取者會尋找標準環境變量：AWS 訪問密鑰、NPM 發布令牌、SSH 密鑰以及包含數據庫憑據的 .env 配置。

然而，我對 TeamPCP v18.95.0 有效載荷的安全分析揭示了一個明顯的現代轉變：自動收集 AI 開發者助手憑據。

該惡意軟件專門在本地配置路徑中搜索活躍的基於終端和基於 IDE 的 AI 代理，包括：

  • ~/.config/claude-code/config.json (包含 API 密鑰和會話令牌的 Claude Code 配置文件)
  • ~/.config/github-copilot/
  • ~/.gemini/ API 配置和密鑰
  • 包含 VS Code Copilot 令牌的 IDE 安全存儲文件夾

為什麼 AI 密鑰成為新的高級目標

情況是這樣的：隨著軟體工程採用代理環境，開發人員通常在終端會話中直接運行具有高權限的 AI 實用程序（如 Claude Code）。這些工具通常被授予寫入文件、運行測試和執行終端命令的權限。

如果攻擊者竊取了你的 AWS 密鑰，他們將獲得雲端運算訪問權限。如果攻擊者竊取了你活躍的 Claude Code 會話密鑰，他們將獲得存儲庫的交互式、基於代理的控制台。可以指示該代理讀取您的整個私有代碼庫，定位邏輯漏洞，編寫靜默後門，提交拉取請求，並在您的名義下提交更改。

對於威脅行為者來說，活躍的 AI 開發者令牌是終極的樞紐密鑰。

構建安全的防禦性工作區

保護現代開發工作區需要擺脫 IDE 是安全沙盒的假設。這是我保護您的機器的務實手冊。

強制執行工作區開發容器 (Dev Containers)：

開發人員應將本地機器視為不受信任的環境。不要運行對主機機器環境變量具有完全訪問權限的 IDE，而是使用 開發容器 (Dev Containers) 或容器化的執行循環。

透過將環境包裹在 devcontainer.json 配置中，可以隔離實際的密鑰：

// devcontainer.json (我的標準安全容器設置)
{
  "name": "Secure Node Workspace",
  "image": "mcr.microsoft.com/devcontainers/javascript-node:20",
  "features": {
    "ghcr.io/devcontainers/features/common-utils:2": {}
  },
  "containerEnv": {
    "AWS_ACCESS_KEY_ID": "${localEnv:AWS_ACCESS_KEY_ID}" // 保持本地憑據屏蔽
  },
  "customizations": {
    "vscode": {
      "settings": {
        "extensions.autoUpdate": false // 阻止擴展在我背後自動更新
      }
    }
  }
}

專家提示：保持碧昂絲法則生效

開發者憑據的碧昂絲法則在這裡適用：如果你喜歡它，你應該給它加把鎖。 永遠不要在自動化系統中使用通用的個人訪問令牌 (PAT)。實施受限細粒度令牌，其訪問權限被限制在特定存儲庫，並對包元數據具有只讀權限。

結論

代碼生成正式成為一個已解決的問題，現在的工程主戰場是憑證的編排和遏制。停止讓 IDE 擴展盲目自動更新，在容器中隔離您的工作區，並保護您的本地 AI 配置。

參考與官方來源