Megalodon在6小時內把GitHub Actions變成5,561個儲存庫的後門

一場自動化的行動在5月某個週一上午6小時內，向5,561個GitHub儲存庫推送了5,718次提交。提交看起來像例行的CI維護工作（「ci: add build optimization step」、「build: improve ci performance」、「chore: optimize pipeline runtime」），來自build-bot、auto-ci、pipeline-bot這類毫不起眼的作者。等到5月18日上午結束，這些儲存庫中每一個裡頭都已多出一個工作流檔案，內含一段base64編碼的bash酬載。

這場行動名為Megalodon。SafeDep的研究團隊於5月21日對外揭露——他們先拆解提交，再沿著製品的痕跡追到位於216.126.225.129:8443的單一指揮控制伺服器。值得注意的不是GitHub遭到攻擊。值得注意的是攻擊者根本不必入侵GitHub。他們使用了GitHub Actions——那套專為保證程式碼完整性而設計的CI/CD系統——當作後門的投遞工具。

兩種工作流：一個大量，一個潛伏

Megalodon以兩種模式運作。大量變種新增了一個名為SysDiag的工作流檔案，在每次push與每次pull request時觸發，把經過它的一切全部取走。鎖定變種Optimize-Build更有耐心：它把既有的工作流替換為workflow_dispatch觸發器，讓它一直沉睡，直到有人手動呼叫。一個躲在專案CI目錄裡的潛伏後門，比一個叫SysDiag的新工作流難察覺得多——因為大多數維護者不會去稽核自己曾經寫過的檔案。

工作流一旦執行，酬載就會把CI環境裡能觸及的一切都讀過一遍。CI環境變數。AWS的存取金鑰、機密金鑰與工作階段權杖。GCP的存取權杖。SSH私鑰。.npmrc憑證。Docker組態。Kubernetes組態。GitHub Actions的OIDC權杖讓攻擊者能以工作流本身的身分，對該工作流被授權的任何雲端帳號冒名出席。離開前，酬載會用grep在儲存庫原始碼裡掃過30種以上不同的機密樣式（API金鑰、密碼、憑證片段），以防有人把它們貼了上去。AWS IMDSv2、GCP與Azure的中介資料端點也會被查詢，以取得雲端機器身分。

把自己的後門出貨的管線

目前最嚴重的受害者是Tiledesk——一個開源的客戶互動平台，九個GitHub儲存庫全遭波及。5月19日至21日之間，Tiledesk把已內建後門的tiledesk-server套件發布到npm上。@tiledesk/tiledesk-server的2.18.6至2.18.12版本如今都帶著酬載程式碼，由所有在那段視窗中執行了npm install的下游開發者裝了上去。這正是Megalodon要的槓桿：在一個開源專案裡植入後門，讓它的發行管線替它把後門散到數以百計的相依專案中。

Black-Iron-Project損失了八個儲存庫。數以百計的小型專案（個別開發者帳號、大學叢集、被遺忘的沙箱）各被波及一兩個。攻擊者似乎並不挑選目標。樣式是覆蓋優先於精準：隨機八字元使用者名稱的一次性帳號，分分鐘鐘地推送相同的提交訊息。C2伺服器靜靜地記錄回傳內容。

為何CI檔案躲過了稽核

這次攻擊之所以成功，也是它將在2026年餘下時間裡繼續上演的原因。CI/CD管線的設計底層就是信任。一個會懷疑下載中怪異二進位檔案的開發者，會毫不猶豫地執行上週才出現在自己儲存庫的工作流檔案——因為工作流檔案的本質就是這個：平台應當執行的程式碼。稽核日誌是有的，但很少有團隊真的去讀。新提交以build-bot、ci-bot這樣的名字到來。diff很小。工作流最底下的那串base64是有意做得不透明的。

防禦劇本既簡單又令人不悅。把5月18日到現在任何碰過儲存庫的祕密全部輪替。稽核管理範圍內每個專案的.github/workflows目錄。檢視那些作者電子郵件與任何已知團隊成員不相符的提交。把Actions檔案裡任何base64區塊視為有罪，直到被解碼為止。使用Tiledesk的組織應該退回到2.18.5或等待乾淨的釋出版。Actions與任何雲端供應商之間握有OIDC信任的人，都應該撤銷並重新發行那段信任關係。

Megalodon是這種規模上第一個把CI工作流本身視為軟目標的行動。不會是最後一個。這次攻擊留下的教訓，開發者其實早就用更小的聲音聽過：管線中你沒有讀的那部分，就是攻擊者替你寫好的那部分。