Nx Console VS Code 擴充功能供應鏈攻擊事件解析

惡意擴充功能如何運作

被植入的擴充功能在表面上仍然像正常工具運作，但當開發者打開任何 workspace 時，就會執行隱藏的惡意邏輯。

研究人員發現它會從 Nx 的 GitHub 基礎設施中下載一個 約 498KB 的混淆 payload，然後在本地執行。

這個 payload 是一個多階段的 憑證收集器（credential harvester），專門針對開發者環境設計。

被鎖定的憑證類型

惡意程式會掃描本地檔案與環境變數，尋找常見的高價值認證資料，包括：

• GitHub tokens 及 GitHub Actions secrets
• npm tokens 與 OIDC 憑證
• AWS credentials、IAM 認證與 Secrets Manager tokens
• Kubernetes 設定檔與叢集憑證
• HashiCorp Vault tokens
• SSH 私鑰
• Docker credentials
• Google Cloud 憑證
• API keys 與資料庫 connection strings
• 若開啟 op session，亦會嘗試讀取 1Password CLI vault 資料

收集到的資料會透過 HTTPS 請求、GitHub API 或 DNS 通道外傳，讓攻擊者可以迅速將敏感憑證帶離受害機器。

惡意程式如何建立持久化（Persistence）

除了竊取憑證，惡意程式還會嘗試在系統中留下長期後門。

Nx 安全通告列出幾個典型痕跡：

• ~/.local/share/kitty/cat.py

• ~/Library/LaunchAgents/com.user.kitty-monitor.plist

• /var/tmp/.gh_update_state
• /tmp/kitty-* 臨時檔案

系統亦可能出現：

• 執行 cat.py 的 Python process
• 帶有環境變數 __DAEMONIZED=1 的程序

不同系統的持久化方式略有不同：

• macOS：利用 LaunchAgent 在開機時自動啟動
• Linux：嘗試透過系統設定或 sudoers 注入保持存取權

即使刪除擴充功能，如果這些持久化機制仍然存在，攻擊者仍可能繼續存取系統。

為何這次事件特別重要

這次攻擊其實不是 Nx 生態系第一次被鎖定。

在 2025 年 8 月，攻擊者已經成功對 Nx npm 套件發動大型供應鏈攻擊，發布帶有惡意程式的 nx 版本與相關插件。那些套件會掃描本地系統並將憑證上傳到攻擊者控制的 GitHub repository。

2026 年的 VS Code 擴充事件反映出兩個重要趨勢：

• 開發者工作站已成為高價值攻擊目標，因為裡面通常有雲端、CI/CD、以及 repository 存取憑證。
• 供應鏈攻擊正轉向開發工具本身，例如 IDE 擴充、build 工具與 package registry。

Nx 團隊表示，這次惡意發布是因為一名開發者帳號早前在另一宗安全事件中被盜，攻擊者利用該 GitHub 憑證繞過正常的發布流程。

哪些用戶可能受影響

如果你在以下時間安裝或自動更新到 Nx Console 18.95.0，就有潛在風險：

• Visual Studio Marketplace：2026‑05‑18 12:30–12:48 UTC
• OpenVSX Registry：2026‑05‑18 12:33–13:09 UTC

可能受影響的環境包括：

• Visual Studio Code
• VS Code 相容編輯器
• 使用 OpenVSX 安裝擴充功能的開發環境

如果你的系統在該時間段內安裝過該版本，建議直接視為 可能已被入侵。

入侵指標（IOC）

開發者應立即檢查以下跡象：

• 安裝過 Nx Console 18.95.0
• 檔案存在：~/.local/share/kitty/cat.py
• 檔案存在：

  ~/Library/LaunchAgents/com.user.kitty-monitor.plist

• 檔案存在：/var/tmp/.gh_update_state
• 出現 /tmp/kitty-* 臨時檔案
• 系統有 Python process 正在執行 cat.py
• 有程序包含 __DAEMONIZED=1 環境變數

如果任何一項成立，應把該系統當作已被入侵處理。

即時修復建議

若懷疑曾受影響，安全團隊或開發者應立即採取以下措施：

1. 更新 Nx Console 至 18.100.0 或以上版本。
2. 終止惡意程序，例如 cat.py 或帶有 __DAEMONIZED=1 的程序。
3. 刪除所有持久化檔案。
4. 在 macOS 先卸載 LaunchAgent：

5. 全面輪換憑證，包括：

   • GitHub tokens
   • 雲端平台憑證
   • API keys
   • SSH keys
   • CI/CD tokens

6. 檢查 GitHub、雲端平台及 CI 系統的 audit logs 是否出現異常活動。

如果確認系統被入侵，最安全的做法通常是 重新安裝或重建工作站環境，並從乾淨來源重新部署憑證。

安全上的重要啟示

這宗事件再次提醒一個現實：現代軟件供應鏈已經延伸到開發工具本身。

IDE 擴充、build system、package manager 等工具往往擁有對源碼、憑證和雲端資源的廣泛存取權，因此成為攻擊者極具吸引力的入口點。

即使只存在 幾分鐘的惡意更新，也足以讓攻擊者在開發者環境中收集大量高價值憑證。

對企業而言，最佳防禦包括：監控擴充功能更新、強制定期憑證輪換，以及把開發者工作站視為 關鍵基礎設施的一部分。