- Researcher Ben Zimmermann reports 26,400 distinct credentials in public Gitee code that the issuing services still accepted, mostly cloud and AI keys.
- Scanners read full commit history, so a key deleted from the code can still be found. Revoking it at the provider is what ends the risk.
- Check that your secret scanner covers the services you use. In this study each of the two tools found only about half of the total.
A deleted key is still a copied key
A developer pushes a key to a public repository, notices, and removes it. The problem feels solved. A new study of public Gitee code shows how many working keys sit in public repositories. Because scanners read full commit history, a deleted key can still be found. Ben Zimmermann, an independent security researcher, went through 7,256,531 public repositories on Gitee, a Chinese code-hosting service. He pulled out 26,400 distinct secrets that the issuing companies still accepted. The lesson here is that deleting a key fixes the code but not the exposure. The key has to be revoked at the provider.
What the research found
Zimmermann's findings were published on MongoDB's blog. Every repository went through a pair of tools, TruffleHog and Kingfisher. For each candidate secret, both tools made a live request to the issuing vendor's service. They discarded anything the vendor did not authenticate. The 26,400 figure counts each secret once, even if it appeared in several places.
Alibaba Cloud AccessKey pairs led the list. Zimmermann says roughly 1 in 766 Gitee repositories held a working one. Behind them, The Hacker News lists YouTube API keys at 3,805, DeepSeek keys at 3,170, keys for Zhipu's BigModel AI platform at 1,489 and OpenAI keys at 1,348.
Zimmermann also reports a live administrator-level credential for an unnamed major enterprise AI platform. The Hacker News says he did not identify the platform or describe what access it gave. By commit date, 12,242 of the credentials, close to half, came from 2025. Some dated to the late 2000s.
Why old keys still work
Git stores the full history of a project. A scanner that reads every past commit will find a key that was removed from the current files. Zimmermann notes that secrets buried deep in history persist.
Verification is simple. The scanner presents the key to the service that issued it. If the service accepts it, the key is live. Anyone else can run the same test. The Hacker News cites TruffleHog's maker, Truffle Security, saying that deleting a key or rewriting history does not revoke it.
The cost of a live key depends on the service. OpenAI says a compromised key lets another person use the account's quota without consent, which can mean unexpected charges and interrupted access. Google, as cited by The Hacker News, treats a YouTube API key as a Google Cloud key that identifies a project. If no API restrictions are set, it works across all the APIs that accept such keys.
One scanner found about half
The Hacker News reports that TruffleHog found 12,737 working credentials and Kingfisher found 14,664. Only 1,001 were found by both. TruffleHog found 9,428 Alibaba Cloud keys to Kingfisher's 993. Kingfisher found all 1,489 Zhipu keys because TruffleHog has no detector for that service.
One caveat belongs here. MongoDB makes Kingfisher, and the post was developed with its Kingfisher team. The overlap figures come from a study with a stake in the answer. The practical point still holds: a scanner only finds the services it knows about.
What the Gitee comparison does not show
On The Hacker News's figures, Gitee had 3.64 working credentials for every 1,000 repositories. Earlier scans of GitLab and Bitbucket, which used TruffleHog alone, found 3.11 and 2.39. Counting only TruffleHog's results, Gitee's rate is 1.76. That count leaves out services TruffleHog cannot detect. So the figures do not show which platform leaks more.
Other limits apply. The scan ran for about a month, and the dates were not given. It is unclear how long ago the keys were tested, or whether anyone else used them. Zimmermann says revocation status had not been confirmed.
Who carries the risk
Zimmermann emailed the vendors with the most exposed keys and gave each a list. He wrote to the vendors, not to the individual developers, because notifying each one did not scale. He argues that vendor-side revocation is more reliable because it needs no action from the person who made the mistake.
He also sees an imbalance in how reports get handled. In his telling, firms in the West tend to run bounty programs or offer a reachable security contact. Most Chinese companies, he writes, have neither, so a leaked credential may have nobody to receive the report.
Most credentials were committed from personal email addresses such as qq.com, 163.com and gmail.com. Corporate domains named include Huawei, ByteDance, Google, Microsoft and Oracle. Zimmermann calls the corporate-domain counts a floor, since most commits came from personal addresses. The post does not say whether those keys belonged to the companies or to the individuals.
What to ask your team
Start with an inventory. Which AI and cloud provider keys does your organization hold, and who created them? Include staff, contractors and side projects.
Ask whether any of them were ever pushed to a public host, Gitee or otherwise. If so, treat them as exposed and revoke them at the provider. Cleaning the repository is not enough.
Ask what each key can do and what it can spend. Provider-side restrictions and spending limits shrink the damage when a key escapes.
Ask your security team to check that the secret scanner covers the services you use, especially newer AI vendors. In this study, each tool alone missed about half. A key you removed from the code is still a key someone may have copied, until it is revoked at the provider.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: MongoDB (research by independent researcher Ben Zimmermann, developed with the Kingfisher team).
