適用對象：在 GitHub 上開發或管理儲存庫的個人和組織，以及使用 GitHub Actions 或雲憑證（包括 OIDC 聯合）的人。本文依據調查的安全公司的公開文章和一家相關服務商的通知，不涉及攻擊步驟。
続報待ち：この記事は公式発表に合わせて更新します
- 適用對象
在 GitHub 上開發或管理儲存庫的個人和組織，以及使用 GitHub Actions 或雲憑證（包括 OIDC 聯合）的人。
- 已確認的影響範圍查看表格 ↓
- 約 4,800 個帳戶被濫用
- 向 61,764 個儲存庫傳送試探性提取要求
- 有惡意變更的儲存庫
另外3項
- 惡意程式碼執行併傳送出憑證
- 金鑰和雲憑證被竊
- 已發布軟體套件被汙染
列為可能涉及的項目
- 雲端持久化（輪換後仍然存在的設定）
- 尚未確認的事項
- 受影響帳戶和儲存庫的最終數量（調查的各公司統計口徑不同）
- 權杖最初是如何被盜的（除雲服務商的情形外，整個攻擊活動尚未查明）
- GitHub 的官方宣告（截至 11月14日我們檢視時未說明）
另外2項
- 與同一攻擊者此前 10月另一次攻擊活動的關係（A、C 公司不斷言為同一攻擊者）
- 雲服務商權杖撤銷的完成情況（該服務商補充說明撤銷中途停止）
- 現在要做的事查看步驟 ↓
- 檢查是否有不認識的提取要求、分支和 Actions 執行記錄
- 撤銷被攻陷帳戶的權杖、授權和工作階段
- 如果惡意變更可能已執行，請輪換該儲存庫能夠讀取的所有金鑰和雲權限
另外3項
- 檢查雲端是否有在輪換後仍然存在的變更
- 盤點您的權杖和第三方應用程式
- 檢查您自己的應用程式沒有暴露版本控制資料夾
- 查證來源（出處）全部來源 ↓
- GitHub，《Changelog》和《Security》（官方部落格和更新日誌；沒有關於此事的條目；11月14日檢視）— github.blog / github.blog
- 最後查證
- 截至 2026年11月14日
續報計畫與查證紀錄
調查的各公司的文章均發布於 11月12日，並可能有所修訂。截至 11月14日，GitHub 的部落格、更新日誌和狀態歷史中均沒有關於此事的條目。
儲存庫所有者和開發者今天應該做什麼
檢查是否有不認識的提取要求、分支和 Actions 執行記錄
在您的帳戶有寫入權限的每個儲存庫中（包括您作為協作者的組織），檢查 11月10日以來的以下三項。據 A 公司稱，在 61,839 個試探性提取要求中，有 10,431 個發往該帳戶並非所有者的儲存庫，是透過協作者或組織權限到達的。
- 您和隊友都沒有提交過的提取要求。即使標題看起來無害（如更新文件），在大量儲存庫中出現同樣的模式也是一個警告訊號
- 不認識的短期分支，或分支被建立後又刪除的跡象
- Actions 執行歷史中有不認識的執行，或執行編號出現缺口。A、C 兩家公司寫道，攻擊者會在約一分鐘內刪除執行記錄和日誌，因此編號缺口是一條線索。也請檢查組織的審計日誌
如果發現其中任何一項，請繼續往下看。A 公司寫道，有試探性提取要求的帳戶，即使後一階段沒有執行，也應視為已被攻陷。
撤銷被攻陷帳戶的權杖、授權和工作階段
此順序依照 B、C 兩家公司的建議。
- 撤銷個人存取權杖、對第三方應用程式（OAuth 應用程式和 GitHub 應用程式）的授權、SSH 金鑰和活動工作階段，然後只重新建立所需的
- 啟用雙重認證。已經被盜的權杖無需它也能使用，因此先撤銷權杖（本站的看法）
- 關閉試探性提取要求，並刪除不認識的分支。刪除前，請記錄它們是在哪個帳戶下建立的
如果惡意變更可能已執行，請輪換該儲存庫能夠讀取的所有金鑰和雲權限
A、B 兩家公司寫道，如果惡意變更已執行，則該工作流程可用的所有金鑰和雲角色都應視為已被竊取。
- 重新簽發 Actions 金鑰和變數（儲存庫、環境和組織級別）、發布權杖（包括用於軟體套件的）和部署金鑰，並使舊的失效
- 如果您使用 OIDC 存取雲帳戶，請把該雲權限包括在內（下一步）
- 如果您在開發機上建置過可能收到惡意變更的儲存庫，也請輪換該機器可讀取的憑證（SSH 金鑰、雲憑證、軟體套件發布權杖等）。B、C 兩家公司報告了在軟體套件安裝時執行的變更
- 如果您在 11月10日以來發布過軟體套件，請檢查已發布的版本是否含有惡意變更；如果有，請撤回並從乾淨狀態重新發布
檢查雲端是否有在輪換後仍然存在的變更
A 公司列舉的在金鑰輪換後仍然存在的變更包括：改寫 AWS 角色信任策略，以及新增 Azure 聯合憑證（B 公司還提到遺留的 AWS 存取金鑰）。請在審計日誌和當前設定中檢查這兩個方面。
- AWS：新建立的存取金鑰，以及角色信任策略的變更（信任是否擴大到了意料之外的帳戶或條件）
- Azure（Entra ID）：新增到應用程式上、指回某個儲存庫的聯合憑證
另外，作為對利用被盜憑證提升權限的檢查，也請檢視 Google Cloud（異常的服務帳號使用或權杖簽發呼叫）以及 Vault 或 Kubernetes（不認識的 GitHub OIDC 登入）。
即使沒有發現任何異常，也請檢查您的 OIDC 信任條件是否已收窄到儲存庫、分支和環境（見下文「應檢查什麼」）。
盤點您的權杖和第三方應用程式
在 GitHub 設定中，列出以下內容，並移除不需要的或不認識的。
- 個人存取權杖：刪除不用的；對其餘的，限制儲存庫、權限和有效期
- 您授權的 OAuth 應用程式和 GitHub 應用程式，包括為託管或 CI 部署而連線的。對不再使用的，移除其授權
- SSH 金鑰和部署金鑰：移除不用的和沒有所有者的金鑰
- 機器人和自動化帳戶的權限：檢查是否有可以繞過受保護分支規則的
據該雲服務商的通知，該服務商的應用程式需要重新連線。如果您使用它，請按服務商的說明操作。
檢查您自己的應用程式沒有暴露版本控制資料夾
同一服務商解釋說，部分透過 GitHub 部署的應用程式公開了整個建置目錄，因此留在那裡的權杖可能被取得。請檢查您應用程式的公開 URL 是否提供了版本控制資料夾（.git）的內容。如果是，請將其從映象中排除，重新部署，並輪換其中包含的所有憑證。也請檢查您的部署平台是否使用類似的機制。
發生了什麼（依據調查的各公司和相關服務商）
以下內容依據 A、B、C 三家安全公司的公開文章（均發布於 2026年11月12日）以及一家雲服務商的通知（11月12日晚得知，11月13日補充）。這些是各方和調查者自己的說法，尚未得到 GitHub 的確認。除非另有說明，時間均為 UTC。
11月10日，約 12:45
據 A 公司稱，攻擊者開始用被盜權杖，在每個權杖有寫入權限的儲存庫中行動。在每個儲存庫中，它先傳送一個試探性提取要求，然後做出惡意變更，約一分鐘後將其還原，並刪除執行記錄和日誌。B 公司也將第一次惡意變更記在 12:46。11月11日，15:00
A 公司統計的 61,839 個試探性提取要求的時間視窗結束。11月12日，04:36
B 公司統計的 8,093 個有惡意變更的公開儲存庫的時間視窗結束。11月12日，07:40
C 公司統計出超過 63,000 個試探性提取要求的時間。A、B、C 三家公司當天發布了各自的文章。11月12日，22:00（未說明時區）
一家雲服務商發布通知，稱其（11月12日，未給出時間）得知，發給其 GitHub 應用程式的權杖被未經授權的一方用於客戶的儲存庫（服務商的通知）。11月13日，15:54
該服務商補充說，撤銷所有使用者權杖的操作中途停止，GitHub 正在調查（服務商的通知）。
有效的被盜權杖
用試探性提取要求測試能否寫入
↓→
惡意變更
收集 CI 金鑰和雲憑證併傳送出去
↓→
掩蓋痕跡
還原變更，刪除執行記錄和日誌；設定可能仍留在雲端
各來源的數字（請勿相加）
| 來源（角色） | 統計的內容 | 數字 | 備註 |
|---|---|---|---|
| A 公司（最先報告） | 傳送試探性提取要求的帳戶 / 收到的儲存庫 | 4,837 個帳戶 / 61,764 個儲存庫 | 約 92% 仍處於開啟狀態（分母是發往該帳戶並非所有者的儲存庫的 10,431 個提取要求） |
| A 公司 | 惡意程式碼執行併傳送出憑證的儲存庫 | 至少 1,835（別處為 1,806） | 文章中的兩個數字；該公司稱該數字可能是下限 |
| A 公司 | 可發布軟體套件的帳戶 | 至少 50 | 據瞭解，具有 npm、Go、PyPI、Packagist 和 crates 的發布權限 |
| B 公司 | 有惡意變更的公開儲存庫（11月10日12:46 至 11月12日04:36） | 8,093 | 不是程式碼執行的數量。明細合計為 8,096；差異未作說明 |
| B 公司 | 試探性提取要求 | 61,879 個提取要求 / 4,833 個帳戶 / 61,734 個儲存庫 | 不包含在 8,093 中 |
| C 公司 | 試探性提取要求（截至 11月12日07:40） | 超過 63,000 | 約 90% 處於開啟狀態。其中 173 個（19 個帳戶）來自發給某雲服務商 GitHub 應用程式的權杖 |
| 雲服務商（自己的通知） | 在受影響客戶帳戶中發現的試探性提取要求 | 超過 250 | 稱有少數客戶受影響 |
B 公司寫道，其數字來自 GitHub 搜尋，只覆蓋公開儲存庫的預設分支，因此真實總數可能更高。
- 被竊取的內容
- GitHub Actions 金鑰和變數、工作流程權杖、雲憑證（AWS、Azure、Google Cloud），以及開發者和 AI 服務的憑證（A 公司）
- 原因（調查者的說法）
- 濫用有效的被盜權杖，而非 GitHub Actions 的缺陷（C 公司）。提交以真實使用者的名義出現且未簽名，這指向權杖被盜（B 公司的推斷）
- 權杖是如何取得的
- 整個攻擊活動尚未查明。對於透過該雲服務商應用程式而來的部分，C 公司也稱無法查明權杖是如何取得的，且沒有該服務商基礎設施被入侵的證據
- 雲服務商的說法
- 其基礎設施未遭入侵。在基於 GitHub 的部署中，權杖被留在建置目錄的設定檔案中，部分應用程式公開了整個目錄，因此可被取得。少數客戶受影響，已逐一聯絡。該服務商開始撤銷發給該應用程式的所有使用者權杖，並更改了部署流程。該服務商稱，透過其命令列工具的部署、其 API 權杖以及執行中的應用程式不受影響
- 對軟體套件的影響
- B 公司檢查了源儲存庫收到惡意變更的 218 個 npm、Go 和 Packagist 軟體套件。有 3 個軟體套件存在惡意版本（1 個 Packagist，2 個 Go），其清單中合計 5 個版本；未發現其他。PyPI 等未作檢查。A 公司也認為攻擊者的目標是 CI 金鑰，軟體套件汙染是自動發布帶來的副作用
- 與 10月另一次攻擊活動的關係
- A 公司稱，受 10月攻擊活動影響的帳戶在這次更可能被攻擊，但判斷為不同攻擊者的不同行動。C 公司也稱，重疊並不表明是同一攻擊者（被盜權杖會被共享和出售）
- GitHub 官方宣告
- 未說明（2026年11月14日檢視了部落格、更新日誌和狀態歷史）
已知與未知的事項
截至 2026年11月14日的狀態。有新訊息時，我們會更新狀態列。
| 專案 | 已公布內容 | 狀態 |
|---|---|---|
| 約 4,800 個帳戶被濫用 | 有效的被盜權杖被用來傳送試探性提取要求 | 已確認（A、B 公司） |
| 向 61,764 個儲存庫傳送試探性提取要求 | 與之後是否有變更是不同的數字 | 已確認（A 公司；B 公司統計為 61,734） |
| 有惡意變更的儲存庫 | 8,093 個公開儲存庫 | 已確認（B 公司；僅限公開儲存庫和預設分支） |
| 惡意程式碼執行併傳送出憑證 | 至少 1,835 個儲存庫 | 已確認（A 公司；也給出 1,806） |
| 金鑰和雲憑證被竊 | 在程式碼執行的儲存庫中 | 已確認（A、B 公司） |
| 雲端持久化（輪換後仍然存在的設定） | 改寫 AWS 角色信任策略和新增 Azure 聯合憑證（A 公司）；B 公司還提到遺留的 AWS 存取金鑰 | 可能（A、B 公司） |
| 利用 GitHub Actions 的缺陷 | 未使用 | 未包含（C 公司） |
| 已發布軟體套件被汙染 | 3 個軟體套件（1 個 Packagist，2 個 Go），合計 5 個版本（未發現其他） | 已確認（B 公司；PyPI 等未檢查） |
| 雲服務商基礎設施被入侵 | 沒有證據（C 公司）；該服務商否認遭入侵 | 未確認（C 公司、該服務商） |
| 權杖最初是如何被盜的 | 對雲服務商應用程式權杖的一部分已有說明；整體不明 | 調查中 |
| 與 10月另一次攻擊活動的關聯 | A 公司認為是不同的行動；C 公司不作斷言 | 調查中 |
| GitHub 官方宣告 | 未發現 | 未說明 |
| 經確認的受影響組織名單 | 未公布 | 未說明 |
如何解讀：這些數字統計的是不同的東西，且在兩天內有所變動
A 公司的 1,835 是對執行次數的估計，B 公司的 8,093 是有惡意變更的公開儲存庫，C 公司的 63,000 是試探性提取要求。它們並不是同一回事。許多只收到試探性提取要求的儲存庫，可能並沒有變更或竊取。不過，據 A 公司稱，傳送過試探性提取要求的帳戶，即使之後沒有變更，也應視為已被攻陷。
使用有效的被盜權杖可能發生什麼
以下是一般性說明，並不意味著這些情況在此發生了。調查的各公司報告實際發生的情況，見上文「發生了什麼」。
如果權杖有效，攻擊者就能以合法使用者的身份寫入。這裡沒有可利用的 GitHub 功能弱點，軟體更新也無法阻止。如果有寫入權限的帳戶可以修改 CI 工作流程，那麼該工作流程能讀取的金鑰和雲權限會一併成為目標。如果到雲帳戶的 OIDC 信任設定得很寬鬆（任何分支或工作流程都能進入），那麼即使沒有儲存的金鑰，也可以簽發臨時憑證。如果您的帳戶是另一個組織的協作者，損害會超出您自己擁有的範圍。
應檢查 CI 和雲權限的哪些方面
本節不是對受影響各方的評估。依據調查者的報告，它以本站的看法為主，聚焦於您自己的環境中應檢查的內容。
不要大範圍或長期持有權杖
這次被利用的是有效的被盜權杖。將個人存取權杖限定於特定儲存庫和權限，設定較短的有效期，不再使用時刪除（使用細粒度型別）。第三方應用程式只授權其所需的範圍（本站的看法）。
收窄工作流程權限和進入雲端的條件
將工作流程的預設權限設為只讀，僅在需要時授予寫入。將雲端 OIDC 信任收窄到儲存庫、分支和環境，使並非所有工作流程都能進入。為環境金鑰設定審批人，意味著被改寫的工作流程無法直接讀取生產環境金鑰（本站的看法）。
用必需的評審來鞏固分支保護
A 公司寫道，該程式碼包含一種意圖繞過分支保護的機制。不要只依賴檢查名稱：要求程式碼所有者的批准評審，並且不給機器人帳戶留例外（本站的看法）。
檢測執行編號缺口和雲設定變更
這次的情況是執行記錄和日誌被刪除，編號缺口成為線索。保留組織的審計日誌，併為工作流程變更以及雲端存取金鑰建立、信任策略變更和新增身份聯合設定告警。C 公司還建議將 CI 的出站流量限制在允許列表內。
不要把金鑰放在儲存庫裡
除了 CI 金鑰，程式碼歷史中的憑證也會隨任何能讀取它們的人的被盜權杖一同被帶走。關於如何在提交前攔截，請參見用 gitleaks 在提交前攔截金鑰；關於撤銷的順序，請參見GitHub 上暴露的 54 萬條憑證仍然有效。
參考來源（公開記錄）
本文中的事實來自以下公開資訊。GitHub 對此沒有官方宣告（11月14日檢視）。攻擊步驟的細節不在涵蓋範圍內。
- GitHub，《Changelog》和《Security》（官方部落格和更新日誌；沒有關於此事的條目；11月14日檢視）— github.blog / github.blog
- GitHub Status（官方事件歷史；沒有關於此事的條目；11月14日檢視）— githubstatus.com
- 某雲服務商的通知，《Security: GitHub tokens exposed by apps deployed from GitHub》（官方社群論壇；11月12日得知，11月13日補充；11月14日檢視）— community.fly.io
- A 公司（安全公司；最先報告），《wfx-loot campaign pushes CI secret stealer to tens of thousands of repositories》（2026年11月12日；11月14日檢視）— aikido.dev
- B 公司（安全公司），《wfx: GitHub Actions Credential Stealer Hits 8,000 Repos》（2026年11月12日；11月14日檢視）— safedep.io
- C 公司（安全公司），《WFX Phantom: The GitHub Actions Secret Stealer That Deletes Its Tracks》（2026年11月12日；11月14日檢視）— stepsecurity.io
- 媒體：BleepingComputer，《Hackers compromise 4,800 GitHub accounts to steal cloud credentials》（11月檢視；對 A 公司文章的報道）— bleepingcomputer.com
更新記錄
2026-11-14：首次發布。依據三家安全公司的公開文章（均為 11月12日）和一家雲服務商的通知。GitHub 沒有官方宣告。媒體報道有出入時，以各方的原始文章為一手來源。有更多資訊發布時，我們將更新。
延伸閱讀
- 因未撤銷而仍然有效的已公開憑證：GitHub 上暴露的 54 萬條憑證仍然有效
- 另一起以基於 GitHub 的開發為目標的案例：TanStack 和 Nx 供應鏈攻擊
- 撤銷的順序與軟體套件帶來的損害：防禦 npm 供應鏈攻擊
- 保護您的帳戶：GitHub 雙重認證 / 環境變數與 API 金鑰基礎
- 使用合法憑證發生的事件：2026年的入侵都是用合法憑證發生的
- 2026年的其他事件：2026年的資料外洩與網路攻擊