26,400 working keys in public Gitee repositories, and what would have caught them

Based on research published by MongoDB on October 28, 2026, and GitHub's changelog of the same day. Figures are the researcher's own.

A researcher at MongoDB spent a month cloning every public repository they could find on Gitee, China's largest Git hosting platform: 7,256,531 of them. Each one went through two open-source secret scanners, TruffleHog and MongoDB's own Kingfisher, and every candidate secret was tested against the issuing service before it counted. The result was 26,400 unique credentials that still worked at the time of the scan. Among them were thousands of live cloud access keys and an active organisation-admin credential for a major enterprise AI platform.

None of this was a breach in the usual sense. Nobody broke in. The keys were sitting in public repositories, committed along with the code that used them.

What did the scan find?

The single most common live credential was an Alibaba Cloud access key pair: roughly one in every 766 repositories contained one that still worked. AI services made up the next striking group. Kingfisher alone found 2,940 working DeepSeek keys, 1,489 for Zhipu and 1,198 for OpenAI, along with Hugging Face tokens and a long tail of others, from Stripe and Slack to databases and analytics tools.

The age of the leaks is the most useful number in the report. Nearly half of the working credentials, 12,242 of them, were committed in 2025 alone. These are not forgotten keys from a decade ago that happen to survive; they are recent keys that nobody rotated, restricted or set to expire. Most were committed from personal email addresses, so the researcher could not attribute them to companies at scale, though corporate domains from major Chinese and Western technology firms appear among the rest.

The comparison with earlier scans puts the problem in proportion. Truffle Security's scans of public GitLab and Bitbucket repositories found 3.11 and 2.39 working credentials per thousand repositories; Gitee came in at 3.64. The researcher is careful to note that this scan used two tools where the earlier ones used one, and that Gitee's heavy use of Chinese cloud and AI services favours the scanner with better coverage for them. The honest reading is not that one platform is uniquely careless. It is that a few working credentials per thousand public repositories looks like a stable feature of public code.

Why does running two scanners matter?

Because each found roughly half of the total on its own. TruffleHog reported 12,737 unique credentials and Kingfisher 14,664, and only 1,001 were caught by both. TruffleHog dominated Alibaba Cloud keys, while Kingfisher found most of the AI-service keys, including thousands of Zhipu keys that TruffleHog has no detector for. Secret scanners recognise the credential types someone has taught them to recognise. A key from a newer or regional service can pass straight through a scanner that is excellent at everything else.

That is also the gap GitHub announced a change to on the same day. Its push protection, which blocks pushes that contain secrets, has until now relied on predefined patterns for known secret types. GitHub has added a classifier, built with Microsoft, that looks at how a value is used in the surrounding code, so it can block secrets that have no recognisable format. GitHub says that in early results it more than doubled the number of pushes where push protection caught a secret. It is a public preview, off by default, available to organisations with GitHub Secret Protection or Advanced Security, and it uses paid AI credits.

What did the researcher do about it?

They emailed the vendors with the most exposed keys, sending each a coordinated report listing the live credentials for its service and the repositories they came from, to help them work out which of their customers were affected. They did not try to contact each developer individually, reasoning that revocation by the vendor is more reliable at this scale because it doesn't depend on the person who leaked the key doing anything.

What should you take from it?

If your team commits code anywhere public, assume that some of it will be scanned by people with better tooling than yours. The practical steps are not new, but the report is a good reason to check that they are actually in place.

1. Scan your own repositories, including their history, with more than one tool if you can. A key removed in a later commit is still in every clone.
2. Turn on push protection where your platform offers it, and consider GitHub's new classifier if you already pay for Secret Protection or Advanced Security.
3. Make keys expire or rotate them, so that a key committed by mistake stops working on its own. Our guide to sharing an API key securely covers rotation schedules and what the major vendors recommend.
4. Keep keys out of code entirely, in environment variables or a secrets manager. Our guide to sharing .env files with your team covers how to do that without the file itself becoming the leak.

AI keys deserve a special mention. They are the newest category in the report, they are often created quickly by individual developers trying something out, and they can carry real spending power. Treat them like any other production credential: one per person or project, restricted where the provider allows it, and revoked when the experiment ends.

---

Sources (checked on October 29, 2026):
MongoDB: Scanning 7.25 million public repositories on China's largest Git platform for secrets (October 28, 2026) ·
GitHub changelog: push protection beyond predefined secret patterns (October 28, 2026) ·
Truffle Security: scanning 5.6 million public GitLab repositories for secrets

Product names are trademarks of their respective owners. CredenShare is not affiliated with them.