返回首頁資訊安全

軟體供應鏈攻擊是什麼?2026 Miasma 蠕蟲事件全解析與企業防護指南

29 min 分鐘閱讀
#供應鏈攻擊#Miasma#資安#npm#PyPI#AI 開發工具#憑證安全#CI/CD

軟體供應鏈攻擊是什麼?Miasma 蠕蟲事件全解析與企業防護指南

72 秒。這是 Miasma 蠕蟲從入侵一名 Red Hat 員工的 GitHub 帳號,到讓 32 個 Red Hat 官方 npm 套件全部帶毒所花的時間(iThome, 2026)。你的團隊昨天 npm install 拉下來的依賴,今天還值得信任嗎?更麻煩的是,這隻蠕蟲鎖定的不只是套件本身——它把 Claude Code、Cursor 這些 AI 開發工具的設定檔變成了感染入口。

事件還在進行中。2026 年 6 月 8 日起,完整攻擊工具包已經在 GitHub 上公開,任何人都拿得到(The Register, 2026)。

這篇文章把多家媒體與資安公司的分析整理成一份企業可以直接用的指南:軟體供應鏈攻擊是什麼、Miasma 事件的完整時間線、為什麼 SLSA 簽章與 hash 比對這次全部失守,以及你的團隊現在就該做的自查與憑證防護動作。全文聚焦防禦視角,不涉及攻擊操作細節。

文章主視覺,呈現供應鏈攻擊「污染上游、擴散下游」的核心概念

軟體供應鏈攻擊是什麼?從 Miasma 事件看懂攻擊原理

軟體供應鏈攻擊(supply chain attack)指的是:攻擊者不直接入侵目標,改為污染目標所信任的上游元件——開源套件、開發工具、CI/CD 管線。2026 年 6 月 1 日的 Miasma 事件就是教科書案例:駭客入侵一名 Red Hat 員工的 GitHub 帳號後,72 秒內讓 32 個 Red Hat 官方 npm 套件帶毒(iThome, 2026)。

為什麼攻擊者偏好這條路?因為效率。

直接入侵一家企業,得一家一家打。但污染一個熱門套件,所有安裝它的下游專案會自己把惡意程式碼拉進來。套件管理器、自動化建置、依賴更新——這些讓開發變快的機制,同時也是惡意版本擴散最快的高速公路。

打個比方:闖空門一次只能偷一戶,在水源下毒卻能影響整個社區。供應鏈攻擊就是後者。

還有一層更不舒服的事實。現代專案的依賴樹動輒數百個套件,每個套件又有自己的維護者、自己的 CI 流程、自己的帳號安全水準。你能掌控自己團隊的資安紀律,卻管不到依賴樹裡第四層那個套件維護者有沒有開雙因素驗證。對資安概念還在建立中的團隊,我們建議先從企業資訊安全基礎指南補齊 threat model 的基本觀念,再回頭看這次事件會更有感。

Miasma 事件之所以讓整個產業緊張,不在於單一受害者多慘,而在於它示範了這條攻擊路徑可以多快、多自動化。接下來我們把整條時間線攤開。

Miasma 蠕蟲事件完整時間線:從 Shai-Hulud 到攻擊工具包開源

這場攻擊的源頭要追到 2025 年 9 月:自我複製蠕蟲 Shai-Hulud 首次現身 npm 生態系;2026 年 5 月,駭客組織 TeamPCP 公開其原始碼後變種湧現,其中最受矚目的就是 Miasma(iThome, 2026)。從開源到大規模攻擊,中間只隔了一個月。

完整時間線如下:

時間事件規模與細節
2025 年 9 月Shai-Hulud 蠕蟲首現 npm 生態系自我複製蠕蟲的起點(iThome
2026 年 5 月TeamPCP 公開 Shai-Hulud 原始碼變種湧現,Miasma 是最受矚目的一款
2026-06-01Miasma 入侵一名 Red Hat 員工 GitHub 帳號72 秒內感染 32 個 Red Hat 官方 npm 套件(iThomeINSIDE
2026-06-03第二波 npm 感染同時感染 57 個 npm 套件、散布超過 286 個惡意版本(iThome
2026-06-05微軟貢獻者帳號遭入侵向 Azure/durabletask 植入惡意 commit;GitHub 偵測後 105 秒內分兩波停用 73 個微軟相關儲存庫(The Register
2026-06-07資安公司 Socket 揭露 PyPI 攻擊波「Hades」入侵 19 個套件、上傳 37 個惡意版本,受害者多為生物資訊研究工具(iThome
2026-06-08 至 06-09完整攻擊工具包開源以「Miasma-Open-Source-Release」名義在 GitHub 公開(The RegisteriThome

視覺化事件完整時間線與規模升級

幾個細節值得放大看。

6 月 5 日的微軟事件,影響的不是邊緣專案:受波及的包括 Azure Functions Host 與 Durable Task 全生態系,橫跨 .NET、Go、Java、JavaScript、MSSQL、Python 六種實作(INSIDE 引 Cloudsmith 分析, 2026)。StepSecurity 技術長 Ashish Kurmi 的分析也指出,GitHub 是在偵測到異常後,於 105 秒內分兩波執行停用(The Register, 2026)。平台方的反應速度其實不慢,但攻擊更快。

6 月 7 日的 Hades 波則證明這不是 npm 獨有的問題。Socket 揭露的這波攻擊轉向 PyPI,受害套件多為生物資訊研究工具——dynamo-release、spateo-release 等——累計下載量達數十萬次,惡意版本會強制安裝 Bun 執行環境來執行混淆酬載(iThome, 2026)。研究機構與學術圈,平常不太被當成供應鏈攻擊的主要目標,這次直接中彈。

一個提醒:本文時間線以 2026 年 6 月 10 日已驗證的公開報導為界。工具包既然已經開源,後續出現新攻擊波的機率不低,請以各資安廠商的最新公告為準。

為什麼 AI 開發工具成為新攻擊面?Claude Code 與 Cursor 的設定檔注入機制

Miasma 最值得企業警惕的創新,是把 AI 程式助手變成感染入口:它將惡意設定檔注入 Claude Code、Gemini CLI、Cursor、VS Code 等 13 種 AI 開發工具,開發者只要開啟受感染的專案就會自動觸發,隨即收割密碼、SSH 金鑰與雲端憑證(iThome, 2026)。

注意這句話的可怕之處:不需要你執行任何可疑檔案

傳統的惡意套件至少要等你安裝、執行。但 AI 程式助手為了「理解你的專案」,會在你打開資料夾時自動讀取專案層級的設定檔。這個為了開發體驗而設計的機制,被 Miasma 拿來當扳機。AI 工具的權限越大、整合越深,這個攻擊面就越寬。

收割的範圍有多廣?根據 iThome 引述的分析,竊取目標涵蓋(iThome, 2026):

  • 程式碼平台與套件庫:GitHub、NPM、PyPI、RubyGems、JFrog
  • CI/CD 與基礎設施:CircleCI、Kubernetes、Vault、Docker
  • 雲端與 AI 服務憑證:AWS、GCP、Azure(GCP 與 Azure 為深度收割)、Anthropic
  • 本機敏感資料:SSH 金鑰、環境變數、Claude 與 MCP 設定檔

看到「Claude 與 MCP 設定」出現在清單裡了嗎?攻擊者很清楚 AI 開發工具的設定檔裡藏著什麼——API Key、MCP 伺服器憑證、雲端帳號的存取權。Hades 波甚至把惡意流量偽裝成向 Anthropic API 發送的請求,混在正常的 AI 工具流量裡規避監控(iThome, 2026)。

我們團隊自己每天都在用 Claude Code 和 Cursor,事件爆發後第一件事就是做了一輪內部檢視。盤點下來最直接的心得是:AI 工具設定檔裡的憑證數量,比我們自己以為的多——MCP 伺服器、雲端 CLI、測試用的 API Key,平常根本沒人逐一記得。如果你的團隊也重度使用 AI 開發工具,我們建議照同樣的順序自查一次,並搭配 API Key 管理與安全完整指南把保管規則補起來。

這也呼應了 OWASP 對 LLM 應用風險的提醒:AI 工具鏈本身就是新的攻擊面,細節可以參考OWASP LLM Top 10 風險解析。順帶一提,AI 開發工具的能力越強、滲透率越高,這個面就越值錢——就像我們在 Claude Fable 5 完整解析裡描述的,AI 助手正在接管越來越大比例的開發流程。能力與風險,從來都是同一條曲線。

說明 AI 開發工具設定檔如何成為感染與憑證收割入口

為什麼傳統供應鏈防禦這次失效?SLSA、簽章與 hash IoC 全數失守

INSIDE 引述 Cloudsmith 的 2026 年分析給出了關鍵結論:Miasma 不利用 GitHub 或 npm 的任何軟體漏洞,而是劫持信任機制——用竊得的合法維護者憑證搭配正常 OIDC token 發布,惡意套件帶著有效的 SLSA provenance attestation,傳統掃描工具難以分辨(INSIDE, 2026)。

換句話說:每一道防線都正常運作,卻全都沒擋住。

怎麼會這樣?我們把三道傳統防線逐一對照。

第一道防線:簽章與 provenance——證明了「誰發布」,沒證明「發布者沒被劫持」

SLSA provenance 的設計目的,是證明套件確實由宣稱的來源、經宣稱的流程建置。問題在於,Miasma 用的是真的維護者憑證、走真的發布流程。簽章驗證的每一步都通過,因為流程本身沒有造假——造假的是流程背後的人。

這裡有個多數討論忽略的盲點:業界這幾年把供應鏈安全的重心壓在「驗證產地」上,但產地證明的有效性,前提是維護者帳號本身安全。當攻擊成本從「偽造簽章」變成「偷一組憑證」,整套信任鏈最貴的環節反而成了最便宜的突破口。防禦的重心,應該從驗證產出物移回保護身分憑證。

第二道防線:hash 比對 IoC——每個受感染版本都長得不一樣

傳統威脅情資的做法,是把已知惡意檔案的 hash 做成 IoC(入侵指標)清單,讓掃描工具比對。但 Cloudsmith 的分析指出,Miasma 為每個受感染版本生成獨立的加密酬載,hash 比對直接失效(INSIDE, 2026)。你拿到的 IoC 清單,永遠慢一步。

第三道防線:C2 流量監控——指揮通道藏在 GitHub 裡

多數企業防火牆會監控對可疑中繼站(C2)的連線。Miasma 乾脆不用傳統 C2:它把 GitHub 的 commit 搜尋功能當成指揮通道,並維持 3 條獨立加密頻道(iThome 引 SafeDep 分析, 2026)。對 GitHub 的流量,哪家開發團隊的防火牆會擋?

更具威懾性的是「失效安全開關」(Dead Man's Switch)設計:受害者一旦撤銷被竊的 token,蠕蟲就刪除整個家目錄,commit 訊息裡還留下「DontRevokeOrItGoesBoom」的警告字樣(iThome, 2026)。連最直覺的應變動作——馬上撤銷憑證——都被預判並設下代價。

說明三道傳統防線為何同時失效


不確定團隊的憑證暴露面有多大?

多數企業出事後才發現:AI API 與雲端憑證散在多個平台、多個專案,連完整清單都拉不出來。CloudInsight 協助企業盤點 API 憑證配置與用量現況,把暴露面變成一張看得懂的清單。

👉 需要專業協助?聯繫我們


企業自查與防護檢查清單:SafeDep 建議與憑證輪換實務

針對 Miasma,資安公司 SafeDep 提出了四項具體自查建議:檢查帳號下有無名稱含「Miasma」或「The Spreading Blight」的可疑儲存庫、審視 CI/CD 工作流程有無未授權修改、留意「DontRevokeOrItGoesBoom」警告字樣,以及——不確定就輪換所有憑證(iThome, 2026)。

我們把這四項展開成可以直接執行的清單,並補上憑證輪換的實務順序。再強調一次,以下全部是防禦動作,照做不會碰到任何法律或道德邊界。

第一步:檢查帳號下的可疑儲存庫

到你組織與成員的 GitHub(及其他程式碼平台)帳號下,搜尋名稱含「Miasma」或「The Spreading Blight」的儲存庫。蠕蟲會用受害者的身分建立儲存庫作為散播節點,這是最快的感染指標。有發現就立即視同憑證全面外洩處理。

第二步:審視 CI/CD 工作流程的未授權修改

逐一檢查 workflow 檔案的近期 commit 紀錄:有沒有你的團隊沒人記得改過的變更?特別注意新增的步驟、改動過的發布權限、多出來的 secret 引用。CI/CD 是供應鏈攻擊的放大器,工作流程被動過手腳,後續每次建置都在替攻擊者工作。對 pipeline 安全還沒有制度化檢查的團隊,可以從 DevOps 完整入門指南的流程治理章節著手。

第三步:留意警告字樣與異常 commit

在組織的 commit 歷史裡搜尋「DontRevokeOrItGoesBoom」。出現這個字樣代表蠕蟲已經在機器上運作過,且 Dead Man's Switch 已就位——這時候的應變順序就變得敏感(見下一步)。

第四步:憑證輪換的實務順序——先備份隔離,再輪換

「不確定就輪換所有憑證」是 SafeDep 的明確建議,但 Miasma 的刪檔機制讓「直接撤銷」帶有風險。我們建議的操作順序是:

  1. 先完整備份受影響機器的重要資料(離線備份,不要同步回雲端)
  2. 隔離機器:中斷網路,停止蠕蟲與指揮通道的聯繫
  3. 從乾淨的裝置上輪換憑證:GitHub、npm、PyPI、雲端平台、AI API Key 全部換新,順序從權限最大的開始
  4. 驗證與監控:輪換後監看各平台的登入紀錄與 API 用量,確認沒有殘留的存取

疑似感染的機器該不該自己處理?如果你的組織沒有事件應變經驗,這一步請找專業資安廠商協助,端點層面的偵測與清除可以參考 EDR 與 MDR 服務指南。平時的依賴健檢,則建議把弱點掃描完整指南裡的掃描流程排進例行作業——掃描抓不到這次的 Miasma,但抓得到一大票更常見的已知威脅,基本盤還是要顧。

把 SafeDep 建議與輪換實務整理成可執行清單

對採購雲端與 AI 服務企業的意義:憑證治理與帳務隔離

別以為這只是工程師的事。Hades 攻擊波的竊取清單橫跨 AWS、GCP、Azure、Anthropic 等雲端與 AI 服務憑證,且對 GCP 與 Azure 做深度收割(iThome, 2026)——只要你的企業採購雲端或 AI API 服務,這份清單上就有你的資產。

對採購方來說,這次事件至少給了三個明確的功課。

功課一:API Key 要分專案隔離、給最小權限

一把萬用 Key 走天下,等於把整家公司的額度與資料押在單一憑證上。正確做法是按專案、按環境發 Key,各自設定用量上限與權限範圍——任何一把外洩,損害都被限制在一個隔間裡。Key 的申請、保管與輪換流程,可以參考 OpenAI API Key 完整指南的做法,原則跨平台通用。

功課二:帳務集中可見——異常用量是憑證外洩的早期警報

想一想:如果你的 Anthropic API Key 被偷了,你多久會發現?Hades 把惡意流量偽裝成向 Anthropic API 發送的請求(iThome, 2026),對受害者來說,第一個可觀察的訊號往往不是資安告警,而是帳單上解釋不了的用量。多平台帳務如果分散在不同卡片、不同帳號,這個訊號你根本看不到。把各平台用量收攏到同一個視圖,本身就是一層資安防護——工具面的選擇可以看AI API 管理平台比較

功課三:把憑證治理寫進制度,而不是靠個人習慣

以代理商的視角,我們在協助企業整併多平台帳務時,最常見的盲點不是技術,是「沒有人知道全公司一共有幾把 Key」。離職員工的 Key 還活著、測試專案的 Key 從沒輪換過、同一把 Key 在三個部門流通——這些都不是罕見案例,而是常態。憑證的生命週期管理(建立、授權、輪換、汰除)應該是制度,ISO 27001 資訊安全管理制度指南裡的資產管理框架就是現成的起點。整體採購流程的合規面,也可以對照企業 AI API 採購完整指南逐項檢視。

供應鏈攻擊防護聽起來是大題目,但對採購方而言,落地動作其實就這三件:隔離、可見、制度化。


多平台 API 帳號分散、誰在用哪把 Key 說不清楚?

CloudInsight 提供多平台統一帳務管理:AWS、GCP、Azure 與 OpenAI、Claude、Gemini API 憑證按專案隔離、用量集中可見,異常一眼看出。統一發票與正規合約,採購與治理一次到位。

👉 立即諮詢解決方案加 LINE 即時諮詢


常見問題

Q: 軟體供應鏈攻擊是什麼?

A: 攻擊者不直接入侵目標,而是污染目標信任的上游元件,例如開源套件、開發工具或 CI/CD 流程。以 2026 年 Miasma 事件為例,駭客入侵一名 Red Hat 員工的 GitHub 帳號後,72 秒內就讓 32 個官方 npm 套件帶毒,下游專案安裝時自動把惡意程式碼拉進來(iThome, 2026)。

Q: Miasma 蠕蟲是怎麼感染開發者電腦的?

A: 它把惡意設定檔注入 Claude Code、Gemini CLI、Cursor、VS Code 等 13 種 AI 程式助手,開發者開啟受感染專案時自動觸發,接著收割密碼、SSH 金鑰與雲端憑證(iThome, 2026)。不需要執行任何可疑檔案,開啟專案這個動作本身就是扳機。

Q: 我的專案沒用到 Red Hat 或微軟的套件,也需要自查嗎?

A: 需要。6 月 3 日的第二波同時感染 57 個 npm 套件、散布超過 286 個惡意版本;6 月 7 日的 Hades 波又轉向 PyPI 的 19 個套件,受害者多為下載量數十萬次的研究工具(iThome, 2026)。感染範圍跨生態系且持續擴大,依賴樹的任何一層都可能引入。

Q: 被竊的 token 可以直接撤銷嗎?聽說會觸發刪除檔案?

A: Miasma 設有「失效安全開關」:受害者撤銷被竊 token 時,蠕蟲會刪除整個家目錄,commit 訊息留有「DontRevokeOrItGoesBoom」警告(iThome, 2026)。建議先離線備份並隔離受害機器,再從乾淨裝置輪換憑證;缺乏應變經驗的組織應尋求專業資安廠商協助。

Q: 企業要怎麼防範下一波供應鏈攻擊?

A: SafeDep 建議四項自查:檢查帳號下有無名稱含「Miasma」或「The Spreading Blight」的可疑儲存庫、審視 CI/CD 工作流程有無未授權修改、留意「DontRevokeOrItGoesBoom」字樣、不確定就輪換所有憑證(iThome, 2026)。中長期則應落實 API Key 分專案隔離、用量集中監控與憑證生命週期制度。

供應鏈信任的下一步:把憑證當成持續管理的資產

回顧整起事件:從 6 月 1 日的 72 秒攻陷 Red Hat,到 6 月 8 日攻擊工具包以「Miasma-Open-Source-Release」名義開源(The Register, 2026),Miasma 用一週多的時間證明了一件事:信任機制本身可以被武器化,而且攻擊門檻正在快速下降

工具包開源意味著什麼?意味著下一波攻擊者不需要 TeamPCP 的技術水準。

但恐慌沒有用,動作才有用。把這篇文章收斂成三件事:

  1. 今天就自查:可疑儲存庫、CI/CD 變更、警告字樣,三項檢查一小時內做得完
  2. 這週完成輪換:照「備份→隔離→輪換→驗證」的順序,把不確定的憑證全部換新
  3. 這季建立治理:Key 分專案隔離、用量集中可見、憑證生命週期入制度

說實話,這次事件裡沒有任何一項防禦動作是新發明——都是資安圈講了多年的基本功。差別只在於,Miasma 把「不做的代價」用 72 秒演給所有人看了。你的團隊,打算哪一天開始?

結論段配圖,視覺化「隔離、可見、制度化」三個治理方向


🎯 立即行動

想把 AI API 與雲端採購的憑證治理一次做對?CloudInsight 提供企業級採購代理:多平台憑證按專案隔離、帳務統一管理、統一發票與中文技術支援。

👉 立即諮詢企業方案加入 LINE 官方帳號


延伸閱讀

參考資料

需要專業的雲端建議?

無論您正在評估雲平台、優化現有架構,或尋找節費方案,我們都能提供協助

預約免費諮詢

相關文章