防暴筆記BREACH NOTES
研究報告拆解

Gitee 公開 repo 洩漏 26,400 個仍有效的雲端與 AI 憑證9,473 個 Alibaba Cloud AccessKey、3,805 個 YouTube API 金鑰

防暴筆記編輯部
研究報告拆解

獨立研究者掃描 725 萬個 Gitee 公開 repository，用 TruffleHog 與 Kingfisher 兩個 secret scanner 驗證每個憑證是否仍能使用，找到 26,400 個有效憑證。多數為雲端與 AI 服務金鑰，以 Alibaba Cloud AccessKey（9,473 個）、YouTube API（3,805 個）、DeepSeek（3,170 個）最多。研究者已通報主要廠商但未聯絡洩漏憑證的開發者，也未確認憑證是否已被撤銷。

30 秒看懂
  • 獨立研究者 Ben Zimmermann 掃描 725 萬個 Gitee 公開 repository，用 TruffleHog 與 Kingfisher 兩個 secret scanner 讀取每個 repository 的完整 commit 歷史，驗證每個找到的憑證是否仍能對服務運作，找到 26,400 個有效憑證。多數為雲端與 AI 服務金鑰，以 Alibaba Cloud AccessKey（9,473 個）最多，其次為 YouTube API 金鑰（3,805 個）、DeepSeek（3,170 個）、Zhipu BigModel（1,489 個）、OpenAI（1,348 個）。
  • 掃描器讀取完整 commit 歷史，開發者之後從程式碼移除的金鑰仍可在歷史中找到。26,400 是去重後的憑證數量（同一憑證出現在多個 repository 只計一次）。依 commit 日期，12,242 個憑證來自 2025 年（近半數），部分可追溯到 2000 年代後期。研究者已將曝光最多的廠商的憑證清單通報給廠商，但未聯絡洩漏憑證的開發者，發布時也未確認任何回報的憑證是否已被撤銷。
  • 兩個掃描器找到的憑證重疊很少：TruffleHog 找到 12,737 個有效憑證、Kingfisher 找到 14,664 個，但只有 1,001 個被兩者都找到。TruffleHog 找到幾乎所有 Alibaba Cloud 金鑰，Kingfisher 找到所有 1,489 個 Zhipu BigModel 金鑰（因 TruffleHog 沒有 Zhipu 的偵測器）。Gitee 的有效憑證比率（每千個 repository 3.64 個）高於先前掃描 GitLab（3.11）與 Bitbucket（2.39）的比率。

發生了什麼

想像你在開發一個使用 Alibaba Cloud OSS 的應用程式。你把 AccessKey ID 與 AccessKey Secret 寫進程式碼，commit 到 Gitee 公開 repository 以便與同事協作。隔天你發現不對，趕快把金鑰刪掉、換成環境變數，再 commit 一次。你以為這樣就安全了。

但金鑰已經在 commit 歷史裡。研究者掃描 725 萬個 Gitee 公開 repository、讀取每個 repository 的完整 commit 歷史，用兩個 secret scanner 找到所有憑證，然後逐一驗證每個憑證是否還能對服務運作。你刪掉的金鑰可能還活著，任何人都能用它存取你的 OSS bucket、建立資源、產生帳單。

2026 年 10 月 29 日，The Hacker News 報導獨立研究者 Ben Zimmermann 掃描 Gitee（中國程式碼託管服務）的 725 萬個公開 repository，找到 26,400 個仍有效的憑證。多數為雲端與 AI 服務金鑰，以 Alibaba Cloud AccessKey（9,473 個）最多。

來源：本文整理自 The Hacker News 於 2026 年 10 月 29 日發布的報導，原始研究來自 Ben Zimmermann 於 10 月 28 日的揭露。原文連結，原文發布日期為 2026 年 10 月 29 日。

研究者已將曝光最多的廠商的憑證清單通報給廠商，但未聯絡洩漏憑證的開發者。發布時也未確認任何回報的憑證是否已被撤銷。

掃描方法：兩個 scanner、完整 commit 歷史

Zimmermann 的掃描約一個月，但未提供具體日期，所以不清楚憑證是多久前被測試的、是否有人已使用過。

他對每個 repository 執行兩個 secret scanner：TruffleHog 與 Kingfisher。兩者都嘗試每個憑證是否能對發出該憑證的服務運作，只保留仍有效的。

掃描器讀取每個 repository 的完整 commit 歷史。開發者之後從程式碼移除的金鑰仍可在歷史中找到並計數。

26,400 這個數字是每個憑證計數一次，不管它出現在多少個 repository。依 commit 日期，12,242 個憑證來自 2025 年，近半數。部分可追溯到 2000 年代後期。

洩漏的憑證類型

在 Alibaba Cloud AccessKey（9,473 個）之後，最大的群組是：

  • YouTube API 金鑰：3,805 個
  • DeepSeek：3,170 個
  • Zhipu BigModel AI 平台：1,489 個
  • OpenAI：1,348 個

較小數量的憑證屬於 GitHub、AWS、Google Cloud、Google Gemini。

其中一個憑證是「一個主要企業 AI 平台的活躍組織管理員憑證」，Zimmermann 寫道。他未說明平台名稱或憑證能到達什麼。

有效金鑰的意義

有效的金鑰能做什麼取決於服務。

OpenAI 說被洩漏的金鑰讓其他人可在未經擁有者同意的情況下使用帳戶的配額。這可能造成「資料遺失、意外費用」、用光每月配額、中斷 API 存取。

YouTube API 金鑰是 Google Cloud API 金鑰，用來識別專案。Google 說，若沒有 API 限制，這種金鑰可用於所有接受 Google Cloud 金鑰的 API。

兩個 scanner 的重疊很少

TruffleHog 找到 12,737 個有效憑證，Kingfisher 找到 14,664 個，但只有 1,001 個被兩者都找到。每個工具單獨找到約一半的總數。

TruffleHog 找到幾乎所有 Alibaba Cloud 金鑰。Kingfisher 找到所有 1,489 個 Zhipu BigModel 金鑰，因為 TruffleHog 沒有 Zhipu 金鑰的偵測器，Zimmermann 寫道。

依賴單一 scanner 的團隊應驗證其偵測器是否涵蓋他們使用的服務。

Gitee 與其他程式碼託管平台

中國工信部於 2020 年選擇 Gitee 作為國家開源程式碼託管平台的基礎。

Gitee 的公開 API 受限，2021 年嘗試研究該站的憑證洩漏因此放棄。

Gitee 的比率（每千個 repository 掃描出 3.64 個有效憑證）高於先前掃描 GitLab（3.11）與 Bitbucket（2.39）的比率。這些掃描只使用 TruffleHog，Zimmermann 寫道。

但基於只用 TruffleHog 的結果，Gitee 的比率是 1.76，這個計數排除了 TruffleHog 未涵蓋的服務（例如 Zhipu）。所以兩個數字都不能顯示哪個平台洩漏更多。

如何回應憑證洩漏

報導引述 Truffle Security（TruffleHog 的製作者）的提醒：從程式碼或 repository 歷史刪除金鑰不會撤銷它。

將任何曾出現在公開 repository 的金鑰視為已曝光

即使你之後刪除、即使你重寫 repository 歷史，都要在服務端撤銷金鑰。

各服務的撤銷與檢查步驟

Alibaba Cloud：

  1. 建立新的 AccessKey pair
  2. 將應用程式切換到新金鑰
  3. 停用並刪除舊 pair
  4. 檢查是否有意外費用、是否有你不需要的資源被建立或刪除（Alibaba Cloud 的洩漏回應計畫）
  5. ActionTrail 顯示該金鑰過去 90 天的 API 呼叫，但 OSS 與 SLS 等服務的資料操作必須在各服務自己的日誌中檢查

Google 與 YouTube API 金鑰：

  1. Rotate 金鑰（建立有相同限制的新金鑰）
  2. 更新應用程式使用新金鑰
  3. 刪除舊金鑰
  4. 加上 API 限制，讓金鑰只能用於你需要的 API

OpenAI：

  1. 從 API Keys 頁面立即 rotate 金鑰（如 OpenAI 建議）
  2. 設定支出限制，幫助限制洩漏金鑰造成的費用

未通知開發者的風險

Zimmermann 已將曝光最多的廠商的憑證清單通報給廠商，但未聯絡洩漏憑證的開發者。發布時也未確認任何回報的憑證是否已被撤銷。

這代表任何曾將金鑰 push 到公開 Gitee repository 的人，不能假設金鑰已被撤銷。

你可以學到什麼

站在攻擊者的角度：我掃描 725 萬個 Gitee 公開 repo，讀取每個 repo 的完整 commit 歷史，找到數萬個憑證。然後我逐一驗證每個憑證是否還能用。26,400 個還活著。我拿到 9,473 個 Alibaba Cloud AccessKey、3,805 個 YouTube API 金鑰、3,170 個 DeepSeek 金鑰。開發者可能以為刪掉程式碼就安全了，但金鑰還在 commit 歷史裡。我可以用這些金鑰存取他們的雲端資源、產生費用、竊取資料。

lessons本案的 6 個教訓
  1. 01
    刪除程式碼不會撤銷憑證：從程式碼或 commit 歷史刪除金鑰不會在服務端撤銷它，金鑰仍可被找到並使用。
  2. 02
    單一 secret scanner 不夠：TruffleHog 與 Kingfisher 各找到約一半的總數，只有 1,001 個（4%）被兩者都找到。依賴單一工具會漏掉大量憑證。
  3. 03
    Gitee 的洩漏比率高於 GitLab 與 Bitbucket：每千個 repository 3.64 個有效憑證，高於 GitLab（3.11）與 Bitbucket（2.39）。
  4. 04
    2025 年的憑證佔近半數：12,242 個（46%）憑證的 commit 日期在 2025 年，顯示洩漏仍在持續發生。
  5. 05
    未通知開發者的風險：研究者未聯絡洩漏憑證的開發者，發布時也未確認任何憑證已被撤銷，代表曝光的金鑰可能仍在運作。
  6. 06
    企業 AI 平台管理員憑證洩漏：其中一個憑證是主要企業 AI 平台的活躍組織管理員憑證，影響範圍可能很大。
keywords重點學習：最需要學習的 10 個關鍵字6 個
  1. 01
    Gitee
    中國程式碼託管服務，2020 年被工信部選為國家開源平台基礎，本研究掃描其 725 萬個公開 repository。
  2. 02
    TruffleHog
    Secret scanner 工具，找到 12,737 個有效憑證，幾乎所有 Alibaba Cloud 金鑰都由它找到。
  3. 03
    Kingfisher
    MongoDB 開發的 secret scanner，找到 14,664 個有效憑證，包括所有 Zhipu BigModel 金鑰。
  4. 04
    Alibaba Cloud AccessKey
    洩漏數量最多的憑證類型（9,473 個），包含 AccessKey ID 與 AccessKey Secret，可存取 OSS、ECS 等服務。
  5. 05
    DeepSeek
    中國 AI 服務，洩漏 3,170 個金鑰，顯示 AI 服務憑證洩漏的普遍性。
  6. 06
    Commit 歷史掃描
    Secret scanner 讀取完整 commit 歷史，開發者之後刪除的金鑰仍可被找到。
try today今天就可以來試試約 10 分鐘

全部唯讀，不改任何設定；做完你會知道自己有沒有同樣的破口。

  1. 檢查是否曾將憑證 commit 到公開 Gitee repository
    看到什麼代表什麼：用 git log -p 或 secret scanner 掃描自己的 repository 完整歷史，尋找憑證。
  2. 立即撤銷任何曾出現在公開 repository 的憑證
    看到什麼代表什麼：即使已從程式碼刪除，在服務端（Alibaba Cloud / OpenAI / Google Cloud）建立新憑證並撤銷舊的。
  3. 檢查 Alibaba Cloud ActionTrail
    登入 Alibaba Cloud 控制台 → ActionTrail → 檢視過去 90 天該 AccessKey 的 API 呼叫
    看到什麼代表什麼：尋找未授權的 API 呼叫、資源建立或刪除。
  4. 檢查服務的計費紀錄
    看到什麼代表什麼：OpenAI / Google Cloud / Alibaba Cloud 控制台 → 計費 → 尋找意外的費用或配額使用。
  5. 為新憑證加上限制
    看到什麼代表什麼：Google Cloud API 金鑰加上 API 限制；OpenAI 設定支出限制；Alibaba Cloud RAM 使用最小權限原則。
  6. 用兩個 secret scanner 掃描自己的 repository
    docker run trufflesecurity/trufflehog:latest github --repo https://github.com/org/repo && docker run mongodb/kingfisher
    看到什麼代表什麼：單一工具只能找到約一半的憑證，使用兩個工具以提高覆蓋率。

為什麼要用兩個 scanner

TruffleHog 與 Kingfisher 各找到約一半的總數，只有 4% 被兩者都找到。原因包括：

  1. 偵測器涵蓋範圍不同：TruffleHog 沒有 Zhipu 的偵測器，Kingfisher 找到所有 Zhipu 金鑰。
  2. 正則表達式不同：兩個工具對同一服務的憑證格式可能有不同的正則表達式，遺漏或誤判的情況不同。
  3. 驗證邏輯不同：即使找到相同的字串,驗證是否為有效憑證的邏輯可能不同。

依賴單一 scanner 的團隊應驗證其偵測器是否涵蓋他們使用的所有服務，或考慮使用多個工具以提高覆蓋率。

如果你曾 push 憑證到公開 Gitee repository

  1. 假設金鑰已曝光且仍活躍：即使研究者未聯絡你,也要假設金鑰可能已被找到。
  2. 立即撤銷：在服務端建立新憑證並撤銷舊的，刪除程式碼不會撤銷金鑰。
  3. 檢查日誌與計費：查看 API 呼叫日誌、資源建立紀錄、計費紀錄，尋找未授權的使用。
  4. 加上限制：為新憑證加上 API 限制、支出限制、最小權限原則。
  5. 掃描其他 repository：用 secret scanner 掃描你的所有 repository（公開與私有），確認沒有其他洩漏。

26,400 個憑證還活著。你的可能在其中。今天就檢查。

來源

分享
精選拆解直送信箱

每篇新文章一封：三點摘要、關鍵字定義、今天能做的一件事。