26,400 Live Credentials Sat in Plain Sight on Gitee's Public Repos
More than 26,400 credentials committed to public code repositories on Gitee, the Chinese code-hosting service, were still valid when an independent researcher tested them — a finding disclosed on 28 October that turns a familiar class of developer mistake into a concrete, usable exposure.
The count matters less than the liveness. Most credential-leak disclosures describe material that may already be dead or revoked; in this case the keys were directly verified as working, meaning anyone who copied them from the public code could have used them at the time of disclosure.
Independent researcher Ben Zimmermann surfaced the keys by scanning 7.25 million public Gitee repositories and reported the results on 28 October, according to The Hacker News. The exposed material was dominated by keys for cloud infrastructure and AI services — a distinction that changes what an attacker could actually do with a stolen string.
Two kinds of exposure
Cloud credentials typically unlock compute instances, storage buckets, and managed databases. The realistic abuse cases are resource hijacking for cryptomining or botnets, bulk data exfiltration, and billing fraud — running up charges on someone else's account. AI service keys present a different profile: metered API credit drain, and in some configurations access to model endpoints or associated data.
In both categories the financial damage accrues to the credential holder, not the platform. For a small team running a CI pipeline that published a key months ago, the first sign of trouble can be an invoice.
Why scanning hasn't caught up
That a single researcher's sweep of 7.25 million repositories still yielded tens of thousands of live keys suggests a meaningful share of developers — or their delivery pipelines — continue to ship secrets into public history. Pre-commit hooks and CI checks exist, but adoption is uneven, and the risk is persistent rather than momentary: deleting or editing a file does not remove a secret from repository history. Any key that ever touched a public repo should be treated as compromised until it has been rotated at the provider.
There is also a coverage gap worth noting for the security research community. Much of the automated scrutiny from mainstream secrets-scanning tooling tends to surface material on English-language platforms and repositories, and non-English code forges may not receive the same attention — yet independent scans of those hosts remain a productive source of disclosures, given comparable volumes of committed code.
Assume exposure, don't wait
Holders of any credential that has appeared in a public repository should act on that basis rather than wait to be told. The corrective sequence is the same whether the key was found by a researcher, a scanner, or a stranger: treat the secret as compromised, replace it at the provider, and verify the old one no longer works.
This story is best read as a developer-hygiene prompt, not a takedown of any particular platform — the actionable work is auditing your own exposure.
Checklist for developers
- Scan, including history. Run secret-scanning across your repositories' full commit history, not just the current HEAD. Tools such as gitleaks, truffleHog, or platform-native scanners should be part of pre-commit and CI checks.
- Assume compromise for anything public. If a key ever existed in a public repository, rotate it at the provider immediately — editing the file does not un-expose it.
- Rotate and revoke properly. Create the replacement first, update all consumers, then revoke the old credential and verify it no longer authenticates.
- Prefer short-lived, scoped credentials. Use role-based access, least-privilege scopes, and ephemeral tokens where the provider supports them, so a future leak has a narrow blast radius.
- Watch the billing. Monitor spend and usage alerts on cloud and AI accounts; anomalous consumption is often the first visible symptom of a stolen key.
The finding is a reminder that repository hygiene remains one of the least glamorous but most consequential habits in the developer workflow — and one that applies regardless of which code host a team uses.
Source: The Hacker News, reporting on the disclosure made 28 October 2026.
Gitee 公開儲存庫驚現 26,400 組仍然有效的認證憑證
中國程式碼託管服務 Gitee 上超過 26,400 組提交至公開 code repository 的認證憑證，在獨立研究人員測試時仍然有效——這項於 10 月 28 日披露的發現，將一類開發者常見的錯誤轉化為具體且可被利用的暴露風險。
比數量更值得注意的是其有效性。大多數 credential 洩露事件所涉及的資料可能早已失效或被撤銷；而今次事件中的 keys 是經直接驗證確認仍然運作，意味著在披露當時，任何從公開 code 複製這些 keys 的人都可以直接使用。
據 The Hacker News 報導，獨立研究人員 Ben Zimmermann 透過掃描 725 萬個 Gitee 公開 repository 發現這些 keys，並於 10 月 28 日報告結果。外洩資料以雲端基建及 AI 服務的 keys 為主——這一區別決定了攻擊者實際上可以利用被竊取的字串做些什麼。
兩類暴露風險
Cloud credentials 通常可解鎖 compute instance、storage bucket 及 managed database。現實中常見的濫用情形包括：劫持資源用於 cryptomining 或控制 botnet、大批量資料外洩（data exfiltration），以及帳單詐騙——在他人帳戶上產生大量費用。AI service keys 則呈現另一種風險形態：按量計費的 API credit 被耗盡，以及在某些配置下可存取 model endpoint 或相關資料。
在這兩類情況中，財務損失均由 credential 持有者承擔，而非平台方。對於一個營運 CI pipeline 並在數月前意外發佈了 key 的小型團隊而言，第一個出事跡象可能就是一張帳單。
為何掃描仍未追上
單一研究人員掃描 725 萬個 repository 仍能發現數以萬計的有效 keys，顯示有相當比例的開發者——或其 delivery pipeline——持續將 secrets 提交至公開的 repository 歷史中。Pre-commit hooks 及 CI 檢查工具雖然存在，但採用程度並不一致，而且風險是持續性的而非一時性的：刪除或編輯檔案並不能將 secret 從 repository 歷史中移除。任何曾經出現在公開 repository 的 key，在 provider 完成 rotation 之前，都應視為已遭入侵。
另有一項值得保安研究社群留意的覆蓋範圍缺口。主流 secrets-scanning 工具的自動化檢查，多集中於英文平台及 repository 上的資料，非英文的 code forge 未必獲得同等關注——然而鑑於這些平台提交的 code 數量相當，針對這些主機的獨立掃描仍然一直是有效的披露來源。
假定已暴露，毋須等待
任何曾出現在公開 repository 中的 credential 持有者，都應主動按此前提採取行動，而非等待通知。無論 key 是由研究人員、scanner 還是陌生人發現，補救步驟都相同：將該 secret 視為已遭入侵，在 provider 處更換，並驗證舊的已無法使用。
這則報導最好理解為對開發者衛生習慣的提醒，而非針對任何特定平台的抨擊——真正可行的行動是審視自身的暴露情況。
開發者 checklist
- 掃描，包括歷史記錄。 對 repository 的完整 commit 歷史執行 secret scanning，而非只檢查目前的 HEAD。gitleaks、truffleHog 或平台內建的 scanner 等工具，應納入 pre-commit 及 CI 檢查。
- 凡屬公開者，一律假定已遭入侵。 若 key 曾存在於公開 repository，應立即在 provider 處進行 rotation——編輯檔案並不能撤銷其已暴露的事實。
- 正確地輪換及撤銷。 先建立替代品，更新所有 consumer，然後撤銷（revoke）舊的 credential 並驗證其已無法通過驗證。
- 優先使用短期、範圍受限的 credentials。 在 provider 支援的情況下，採用 role-based access、最小權限（least-privilege）scopes 及 ephemeral tokens，令日後一旦洩露，影響範圍（blast radius）得以收窄。
- 留意帳單。 監控雲端及 AI 帳戶的開支及用量警報；異常消耗往往是被竊取 keys 最先可見的症狀。
這項發現提醒我們，repository 衛生仍然是開發者工作流程中最不起眼卻影響深遠的習慣之一——而且無論團隊使用哪一種 code host，都同樣適用。
來源：The Hacker News，報道了 2026 年 10 月 28 日作出的披露。