這是一個非常典型的供應鏈攻擊案例，但其手法與我們平常聽到的惡意套件（Malicious Package）有所不同。通常我們擔心的是「使用者下載了惡意套件導致電腦中毒」，但這次的攻擊重點在於「利用 GitHub 提供的雲端運算資源來發動攻擊」。
對於 Junior 工程師來說，最需要理解的核心概念是：攻擊者將 GitHub Actions 從一個「自動化部署工具」轉變成了「分散式的攻擊跳板」。
攻擊路徑與技術脈絡
這次事件的起因是一個 PHP 開發者的 GitHub 帳號被盜用。攻擊者在該開發者的 10 個開源專案中植入了惡意內容。然而，有趣的是，這些惡意程式碼並沒有寫在 PHP 函式庫（Library）本身，而是寫在 GitHub Actions 的工作流文件（Workflow YAML files）中。
GitHub Actions 是 GitHub 提供的 CI/CD 服務，允許開發者定義一套自動化流程（例如：每次 Push 程式碼就自動跑測試、部署）。當這些定義好的 YAML 檔被觸發時，GitHub 會啟動一個 GitHub-hosted Runner（由 GitHub 提供的虛擬機環境）來執行指令。
攻擊者正是利用這一點，在工作流中加入指令，讓 GitHub 的伺服器在執行時自動下載 Linux 攻擊載荷（Payload），並將其轉化為掃描器。
攻擊目標與漏洞利用
這些由 GitHub 伺服器運行的掃描器，目標是全球範圍內安裝了 cPanel 或 WHM（WebHost Manager，一種廣泛用於主機管理的公司控制面板）的伺服器。
攻擊者利用的是一個名為 CVE-2026-41940 的身分驗證繞過漏洞（Authentication Bypass）。簡單來說，這個漏洞允許攻擊者在不需要正確密碼的情況下，直接獲取伺服器的管理權限。
一旦成功入侵，攻擊者會立即進行機敏資訊收割（Credential Harvesting），包括： 雲端金鑰（AWS, Google Cloud API keys） 資料庫連線資訊與 SSH 私鑰 GitHub 與 GitLab 的 Token 支付服務金鑰（如 Stripe） 環境變數（Environment Variables）中的秘密設定
為什麼這種攻擊方式很危險？
第一，規避偵測。因為攻擊流量來自於 GitHub 的官方伺服器 IP，許多防火牆或安全監控系統可能會將其視為可信的流量，而不會像攔截來自未知惡意 IP 的攻擊那樣迅速反應。
第二，資源免費且可擴展。攻擊者不需要自己購買伺服器來搭建掃描陣列，只要控制足夠多的 GitHub 儲存庫（Repositories），就能利用 GitHub 提供的免費運算額度，將其變成一個巨大的分散式攻擊網路。
第三，隱蔽性高。由於惡意邏輯存在於 CI/CD 流程而非程式碼邏輯中，一般的靜態程式碼分析工具（SAST）如果沒有掃描 YAML 設定檔，很難發現這個問題。
延伸威脅：Operation Muck and Load
除了上述針對伺服器的攻擊，研究人員還發現了另一個名為 Operation Muck and Load 的行動。這個行動則回到了傳統的誘餌手法，建立大量偽裝成開發工具或加密貨幣錢包的儲存庫，誘導使用者下載包含 PowerShell 腳本的惡意檔案，進而植入遠端控制木馬（RAT）或挖礦程式。
這顯示出攻擊者正將 GitHub 視為一個完整的惡意生態系：既可以用來吸引受害者下載，也可以用來作為攻擊其他伺服器的基礎設施。
實務上的防禦建議
針對開發者與維運人員，這次事件提供了幾個重要的警訊：
首先是帳號安全。開發者帳號被盜是所有災難的起點，啟用多因素驗證（MFA）是最低限度的要求。
其次是權限最小化。在設定 GitHub Actions 時，應嚴格限制 GITHUB_TOKEN 的權限，避免工作流擁有過高的寫入或管理權限。
最後是監控 CI/CD 變更。應將 YAML 設定檔視為程式碼的一部分，必須經過 Code Review 才能合併，避免未經審核的自動化腳本被悄悄植入。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。