26,400 still-valid cloud and AI keys sit exposed in public Gitee repositories
On October 28, 2026, researcher Ben Zimmermann published the result of scanning 7.25 million public Gitee repositories: 26,400 cloud and AI credentials still worked, including 9,473 Alibaba Cloud AccessKey pairs. Removing a key from the code does not revoke it — the only defense is rotation at the provider.
October 28, 2026. Independent researcher Ben Zimmermann published the results of scanning 7.25 million public Gitee repositories, the Chinese code-hosting service. The verdict: 26,400 credentials left in public code still worked when tested — meaning anyone who copied one could have used it. The point that matters: Zimmermann could not confirm that even one of them had been revoked. Deleting a key from the code does not revoke it.
What was sitting in plaintext
The exposed credentials are overwhelmingly cloud and AI service keys. At the top, 9,473 Alibaba Cloud AccessKey pairs, then 3,805 YouTube API keys, 3,170 DeepSeek keys, 1,489 keys for Zhipu’s BigModel AI platform, and 1,348 OpenAI keys. Smaller numbers were found for GitHub, AWS, Google Cloud, and Gemini. In the middle of that list, one anomaly changes everything: one credential was “an active organization-admin credential for a major enterprise AI platform” — Zimmermann named neither the platform nor the scope of the access.
The method matters as much as the result. The scan ran for about a month, without the researcher giving dates. He ran two secret scanners — TruffleHog and Kingfisher, the latter developed with MongoDB — over every repository, reading the full commit history. Each credential was tested against the service that issued it, and only working ones were kept. The direct consequence: a key a developer removed from the code after pushing it is still detected and counted, because it lives on in the history.
Two scanners, two halves of the problem
The study’s most instructive figure is not the total, but the disagreement between the tools. TruffleHog found 12,737 working credentials, Kingfisher found 14,664 — but only 1,001 were found by both. Each tool alone saw only about half of the total. The reason is structural: TruffleHog caught almost all the Alibaba Cloud keys, while Kingfisher found all 1,489 BigModel keys because TruffleHog simply has no detector for Zhipu’s keys.
That is a lesson for any team that relies on a single scanner: a tool only detects what its detectors know how to recognize. Checking that your scanner covers the services you actually use is not a detail — it is the difference between “found nothing” and “looked for nothing.” The right reflex is to cross two engines, as Zimmermann did, and validate detectors against your own vendor inventory.
The temporality of the risk
The distribution over time is revealing. By commit date, 12,242 credentials came from 2025, nearly half the total; some date back to the late 2000s. A key pushed by mistake fifteen years ago can still work today if no one revoked it — the lifetime of a leaked secret has nothing to do with when it leaked.
The measured leak rate — 3.64 working credentials per 1,000 repositories scanned — exceeds the rates from earlier scans of GitLab (3.11) and Bitbucket (2.39), which used only TruffleHog. On TruffleHog’s results alone, Gitee’s rate falls to 1.76 — but that figure excludes services TruffleHog does not cover, such as Zhipu. Zimmermann concludes cautiously that neither figure shows which platform leaks more. An honest comparison would require identical scanners on identical corpora.
What a working key lets someone do
The severity of a key depends on the service that issued it. OpenAI is explicit: a compromised key allows someone else to consume the account’s quota without the owner’s consent, which can cause “data loss, unexpected charges,” a used-up monthly quota, and interrupted API access. A YouTube API key is a Google Cloud key that identifies a project: without API restrictions, it can be used with every API that accepts Google Cloud keys. And an Alibaba Cloud AccessKey pair can mean creating or deleting billed resources.
The recommended response is uniform and fits one sentence, echoed by Truffle Security, the maker of TruffleHog: treat any key that has ever been in a public repository as exposed, and revoke it at the provider. Removing the key from the code or rewriting the repository’s history does not revoke it. The procedures are spelled out per provider: create a new AccessKey pair at Alibaba Cloud, switch your apps to it, then disable and delete the old one, checking for unexpected charges via ActionTrail (90 days of API calls) and each data service’s own logs; rotate the key at Google and add API restrictions to limit it to only the services you need; rotate the key immediately from the API keys page at OpenAI and set spend limits.
# Scan a local repository with two complementary engines
pip install trufflehog3 kingfisher-secrets 2>/dev/null
trufflehog filesystem . --no-update
kingfisher scan . --verify
# Any "verified" key that surfaces must be revoked at the provider, not just removed from the codeVerdict
If you or your team have ever pushed a key to a public repository — Gitee or anywhere else — assume it is compromised and rotate it at the provider now: Ben Zimmermann’s scan shows thousands of pushed keys remain valid years later, and none were confirmed revoked. If you run paid AI models or cloud APIs, add the two reflexes that cost almost nothing: spend limits at OpenAI and API restrictions at Google Cloud to cap the damage of a key that leaks despite you. And if you own a security pipeline, do not trust a single scanner: cross TruffleHog and Kingfisher, and verify their detectors against the list of services your organization actually pays for. Secret leakage is not a code problem, it is a lifecycle problem — and a key’s lifecycle only ends at whoever issued it.