An independent researcher has found 26,400 cloud and AI credentials that still worked in public code on Gitee, China’s largest home-grown Git hosting service, and handed them to the affected vendors rather than to the developers who leaked them. The disclosure is a useful case study in how mass credential reporting works, where it falls short, and why UK organisations cannot assume a key has been revoked just because it was removed from the code.
What happened
On 28 October 2026 Ben Zimmermann, an independent researcher who specialises in large-scale credential exposure, published the results of a scan of 7,256,531 public repositories on Gitee. The write-up appeared as a guest post on MongoDB’s technical blog and was developed with the company’s Kingfisher team, which maintains an open-source secret scanner of the same name. The Hacker News reported the findings the following day.
The scan turned up 26,400 unique credentials that authenticated successfully when tested. Alibaba Cloud AccessKey pairs led with 9,473, followed by YouTube API keys (3,805), DeepSeek keys (3,170), Zhipu BigModel keys (1,489) and OpenAI keys (1,348), with smaller numbers for GitHub, AWS, Google Cloud and Gemini. One was an active organisation-admin credential for an unnamed major enterprise AI platform. Nearly half (12,242) were committed in 2025, so most of this exposure is recent.
Rather than contact thousands of individual developers, Zimmermann sent a coordinated report to the vendors with the highest exposure, listing the live credentials for their service and repository details to help identify affected customers. At the time of publication he had not been able to confirm that any of the reported keys had been revoked.
How it works
The research was a measurement exercise, not an attack. Two secret scanners, TruffleHog and Kingfisher, read the full commit history of each repository and checked candidate credentials with the issuing service, discarding anything that looked like a key but failed to authenticate. Because history was included, secrets later deleted from the current code still counted. The run took about a month and cost a little over $3,000.
The scanners overlapped surprisingly little. TruffleHog verified 12,737 working credentials and Kingfisher 14,664, with just 1,001 caught by both tools, so either tool alone caught roughly half. Kingfisher found every Zhipu key because TruffleHog has no detector for that service. Comparisons with GitLab and Bitbucket are shaky for the same reason: earlier scans of those platforms used one tool, and neither figure proves which platform leaks more.
Zimmermann also makes a point about disclosure routes. On GitHub, providers can join a secret scanning partner programme: when a token matching their format appears in public code, GitHub sends it to the provider’s own endpoint so it can be checked and acted on. Zimmermann notes that Gitee has no public equivalent, and that many Chinese vendors lack the bug bounty programmes or accessible security contacts that Western firms usually offer. That can leave mass reporting by researchers as one of the few ways these keys get noticed at all.
Why it matters for UK organisations
It would be easy to file this under “a Chinese platform problem”. That would be a mistake. Zimmermann’s analysis of committer email addresses found corporate domains from major Western firms, including Google, Microsoft, Oracle, Apple and Meta, alongside Chinese technology companies. Most credentials came from personal webmail addresses, so the corporate figures are a floor, not a ceiling.
For UK organisations the exposure paths are familiar. Development work outsourced to teams or contractors in China, joint ventures and regional subsidiaries that use Alibaba Cloud, open-source projects mirrored to Gitee for developers behind the Great Firewall, and staff experimenting with Chinese AI models such as DeepSeek or Zhipu can all put company secrets in a place the security team never monitors. If your supplier assurance only covers GitHub, you have a blind spot.
Many of the exposed keys are for AI services, which teams often treat as low-risk developer tokens. OpenAI’s guidance, cited by The Hacker News, warns that a leaked key lets others spend your quota and can lead to data loss and unexpected charges.
Finally, there is the question of disclosure itself. UK organisations increasingly publish vulnerability disclosure policies, but few say what they will do when a researcher reports their leaked credentials found on a third-party platform. This case shows that the report may go to your cloud or AI provider, not to you, and you may never hear about it.
Expert view
In my experience, exposed secrets in repositories are among the most reliable findings on any external assessment, and the response is nearly always “but we deleted that”. Deleting a key from the latest file does nothing to the history, and rewriting history does nothing to the key. Only revocation at the provider ends the exposure.
Reporting to vendors rather than individuals was sensible at this scale. As Zimmermann puts it, “vendor-side revocation is the more reliable path”. It does not depend on thousands of developers trusting an email from a stranger. The weakness is that vendors have no obligation to act. Researchers doing this work deserve a clear channel and a reply.
The scanner comparison is what I would show engineering leads. When we test, we often find teams running one scanner and treating a clean result as assurance. A tool with no detector for the AI service adopted last quarter reports nothing, and that silence is easily mistaken for safety.
What to do now
- Revoke, then investigate. Treat any credential that has ever been committed to a public repository on any platform as compromised. Rotate it at the provider, move applications to the new key, then disable the old one. Check billing and audit logs for activity you cannot explain.
- Widen your view of where code lives. Ask development partners, subsidiaries and suppliers which hosting platforms they use, including Gitee and other regional services, and include them in your monitoring and contracts.
- Run more than one scanner. Check that your secret scanning tools have detectors for every cloud and AI service your teams actually use, and scan full history, not just the current branch.
- Restrict keys by design. Apply API restrictions, spend limits and least privilege so that a leaked key is worth as little as possible. This maps directly to the Cyber Essentials user access control and secure configuration controls.
- Get secrets out of code. Use a secrets manager or your cloud provider’s equivalent, with short-lived credentials where possible, and block commits containing secrets with pre-commit checks.
- Update your disclosure policy. Say how researchers should report your exposed credentials, commit to acting quickly, and ask your cloud and AI providers how they will tell you when they receive such a report.
Bottom line
Zimmermann’s scan shows that live credentials sit in public code on a large scale, and that the disclosure process meant to clean them up is patchy outside GitHub. For UK organisations the lesson is simple: assume every key that has touched a public repository is burnt, revoke it yourself, and do not rely on a researcher, a vendor or a platform to do it for you.
Sources
- MongoDB: Scanning 7.25 million public repositories on China’s largest Git platform for secrets
- The Hacker News: 26,400 Valid Cloud and AI Credentials Found Exposed in Public Gitee Repositories
- RuntimeWire: Gitee scan finds 26,400 live credentials across 7.25 million repositories
- GitHub Docs: Secret scanning partner program
