26,400 Working Keys, 7.25 Million Repositories: MyTechDailyNews Breaks Down the Gitee Credential Exposure Scan
By Sarah Chen · MyTechDailyNews, General desk · October 28, 2026 · 7 min read
Somewhere in the normal rhythm of shipping software sits a moment every security team dreads: a developer pastes a live API key into a config file, pushes the demo to a public repository, and walks away. Nothing breaks, no alarm sounds, and weeks later an automated sweep confirms the key is still valid. MyTechDailyNews went through exactly that kind of audit at scale — a guest study by independent security researcher Ben Zimmermann, produced with the Kingfisher team at MongoDB — that swept public code on Gitee and turned a quiet everyday habit into numbers platform owners and ordinary users can no longer ignore.
Ben focuses on large-scale credential exposure research across public source-hosting platforms. In this edition the headline is blunt: the scan reported 26,400 unique verified-live credentials, and the results included an active organization-admin credential for a major enterprise AI platform along with thousands of live cloud provider access keys.
Five numbers that frame everything else
- 7,256,531 unique public Gitee repositories were enumerated and scanned.
- 26,400 unique verified-live credentials survived deduplication by token value.
- 1,704,759 usernames formed the seed corpus used to map a platform with no usable catalogue.
- 3.64 live credentials per 1,000 repositories — the highest density among the three code hosts compared below.
- $3,097.64 of total compute, fully absorbed by a $5,000 sponsorship from Modal, spread over roughly one month of continuous execution.
A national code host that was never designed to be audited
Gitee started in 2013 under OSChina and was later chosen by China's Ministry of Industry and Information Technology as the country's national open-source code hosting platform. That status explains both its scale and its blind spot: measured against GitHub and GitLab, its public API is severely constrained. There is no paginated projects endpoint, and the on-site code-search feature appears to have been retired years ago. A previous attempt to study credential exposure on Gitee back in 2021 gave up, concluding the APIs were too limited to scale the research.
For readers outside China, the practical point is dependency, not geography. Code hosted here ends up inside libraries, toolchains and services that the rest of the world installs. As a surface for leaked secrets, it shares the traits that make any large Git platform risky:
- Because it is Git-based, secrets buried deep in commit history persist even after files are deleted.
- It hosts millions of public repositories with active commit volume.
- It has no public equivalent of the platform-vendor secret-scanning partnerships that have become standard on GitHub.
Step one: building a map when the platform refuses to hand one over
Since the official interface was so thin, the enumeration had to stitch together several surfaces at once: the only official REST endpoint that returned useful data at scale, the platform's Explore feed, per-user repository and stargazer pages on the website, and the internal Elasticsearch widget that powers the on-site search box.
The starting corpus came from a user-search endpoint queried with every three-character prefix — aaa, aab, all the way to zzz — merged with names pulled from the Explore feed and then expanded through each user's following list and the stargazers of popular repositories. That produced 1,704,759 usernames to work from.
Each username then opened two pages on the site itself: one listing the person's own repositories, one listing the repositories they had starred. The first page arrives as full HTML, while later pages load through AJAX pagination and require a CSRF token scraped from that first page.
The part of the platform sitting outside that social graph was reached through the same internal search widget the website uses. A plain Python script asked it for results in pages of 20, under a fixed query ID of 1048, hitting a hard ceiling of 200 results per query no matter how many matches actually existed. For rare usernames that was fine; for common ones and prefix sweeps, the ceiling silently truncated the answer.
The workaround is the interesting part for anyone who has ever fought a search API. Because Elastic responses already carry aggregations that bucket hits by programming language and by license, a capped query was re-run once per bucket, and for prefix queries that became a breadth-first walk down a query tree — split by language, then license, then deeper prefixes until every branch fit inside 200 results. After deduplicating repository IDs across all sources, the working set came out at 7,256,531 unique public Gitee repositories.
Step two: cloning millions of repositories on borrowed compute
The clone-and-scan stage was handled in a single Python script built on Modal, the serverless compute platform better known for AI workloads but comfortable for most parallel jobs. TruffleHog and Kingfisher ran concurrently against every repository, because each surface verified credentials the other missed.
Figure 1 — how the two scanners were plumbed together in one pipeline.
The Docker image behind each job is a multi-stage build that copies both scanner binaries from their upstream releases into one Python base image, then adds git and OpenSSH for cloning. Each repository is bare-cloned over SSH and both tools run against the same on-disk copy.
| Pipeline setting | Value used in the study | What it means for a non-specialist |
|---|---|---|
| Search widget | query ID 1048, page size 20, ceiling of 200 results | Platform-side limits, not researcher impatience, forced all the bucket splitting. |
| Per-repo job limits | 300-second timeout, 0.125 to 2.0 CPU, 256 to 4096 MB memory | Deliberately modest so a job this large can pause and resume without losing work. |
| Concurrency | 350 containers running steadily | Push harder and the clone side starts blocking you. |
| Batching | 50 batches of ~150K repos | Smaller, resumable batches beat one unstable mega-run at this scale. |
Wall-clock time was roughly one month of continuous execution, and per-repository clone speed was the main drag: Gitee's servers sit in China, so network distance across the Pacific plus SSH protocol overhead made every clone materially slower than an equivalent GitHub clone. The finished bill was $3,097.64, fully covered by the $5,000 compute-credit sponsorship from Modal. The architecture is also portable — the same Modal plus dual-scanner setup works against most Git hosts with little more than a clone-URL substitution, and Ben used a smaller-scale version of it in a prior investigation of Algolia DocSearch admin keys.
Step three: what the two scanners actually returned
Both tools authenticate each candidate against the owning vendor's API at scan time — TruffleHog in --only-verified mode, Kingfisher in --only-valid mode — and throw away anything that merely pattern-matches. The 26,400 figure counts each raw secret value once, even if it appears in several repositories or is caught twice.
| Scanner | Unique findings |
|---|---|
| TruffleHog | 12,737 |
| Kingfisher | 14,664 |
| Caught by both | 1,001 |
| Total unique credentials | 26,400 |
Either tool alone would have caught only about half. TruffleHog dominated Alibaba Cloud key detection, 9,428 against 993, while Kingfisher dominated DeepSeek at 2,940 against 230, OpenAI at 1,198 against 150, HuggingFace at 154 against 1, and Chinese AI services such as Zhipu at 1,489 against 0 — vendors TruffleHog has no detector for at all.
Which secrets, when they landed, and who committed them
The single most common leaked credential type was Alibaba Cloud AccessKey pairs: in practical terms, 1 in every 766 Gitee repositories contained a verified-live Alibaba Cloud credential. A long tail of other services — LangSmith, OpenWeather, Algolia, PostHog, OpenRouter, MySQL, Stripe, Slack, Twitter and others — accounts for the rest.
Figure 2 — the same dataset grouped by the vendor that issued the credential.
Timing is the detail that should worry teams planning a quarterly clean-up: the vast majority of verified-live credentials were committed in the last two years, and 2025 alone accounts for 12,242 unique credentials, close to half the entire dataset. This is not ancient history sitting in abandoned archives; it is current work practice.
Figure 3 — unique credentials plotted by the year they were committed.
Attribution by company is mostly impossible, and that is itself a finding. Most credentials were committed from personal mail services such as qq.com, 163.com and gmail.com. The corporate-domain numbers are therefore a floor, not a ceiling — and even that floor spans major Chinese and Western tech companies, with smaller footprints from Oracle, Apple, Meta, Anthropic and others alongside Chinese commercial and academic domains. The reported breadth also includes Huawei, ByteDance, Google and Microsoft.
Figure 5 — unique credentials by committer email domain.
Gitee against GitLab and Bitbucket
The closest published reference points come from TruffleSecurity's scan of 5.6 million public GitLab repositories and the companion Bitbucket scan referenced in that post.
| Platform | Repositories scanned | Verified-live credentials | Per 1,000 repos |
|---|---|---|---|
| Bitbucket | ~2,600,000 | 6,212 | 2.39 |
| GitLab | ~5,600,000 | 17,430 | 3.11 |
| Gitee | 7,256,531 | 26,400 | 3.64 |
Gitee leads on both raw count and per-repository density, but the comparison needs one honest caveat. The earlier scans used TruffleHog alone, while this one ran TruffleHog and Kingfisher together. TruffleHog's detector library skews toward Western vendors, and Gitee carries heavy Chinese-vendor activity — Alibaba Cloud, DeepSeek, Zhipu and others — that Kingfisher's coverage surfaces. Restrict this dataset to TruffleHog-only and Gitee drops to 1.76 per 1,000 repos. The takeaway is about shared developer behaviour, not a league table of platforms.
What the researcher did with the findings
Vendors with the highest exposure volume in the scan received an email containing a coordinated report: the full list of verified-live credentials associated with their service, plus source-repository metadata so they could attribute affected customers. Individual per-developer notification was not pursued at this scale, because vendor-side revocation is the more reliable path — it requires no action from the person who leaked the credential. At the time of writing, revocation status for the disclosed credentials has not yet been confirmed.
Four common misconceptions
- "I deleted the file, so the key is gone." Git keeps history. On a Git-based host, a secret buried in an old commit persists whether or not the current tree still shows it.
- "Only hobbyists leak credentials." The committer metadata names major organisations on both sides of the Pacific, including Huawei, ByteDance, Google, Microsoft, Oracle, Apple, Meta and Anthropic.
- "Our scanner ran a clean pass, so we are fine." In this study either scanner alone caught about half of the verified-live credentials, because detector coverage is largely complementary.
- "Platform-level secret scanning handles this." Gitee has no public equivalent of the platform-vendor secret-scanning partnerships that are now standard on GitHub, so the platform is not doing this work on your behalf.
Action checklist: what to do if you publish code
- Audit your public repositories including full history, not just the latest commit — the persistence of old secrets is what made 7.25M repositories searchable in this study.
- Rotate every credential that has ever appeared in a public repository, and treat the rotation as the fix rather than the deletion of the file.
- Move secrets out of source entirely: environment variables or a secret manager, with committed config files holding placeholders only.
- Turn on whatever secret scanning your host offers, and add a pre-commit check so keys never reach history in the first place.
- Report third-party leaks to the issuing vendor rather than to the individual developer; vendor-side revocation is the more reliable path at scale.
- If you depend on open-source components hosted on Gitee, factor this into your supplier review: personal email domains make company-level attribution nearly impossible.
- For teams, add a named owner for credential incident response. The study covers roughly one month of scanning; the disclosure gap is longer than most internal review cycles.
FAQ
What exactly was found? 26,400 unique verified-live credentials across 7,256,531 public repositories on Gitee, after deduplication by token value.
Does "verified-live" mean the keys were abused? No. It means each candidate authenticated successfully against the issuing vendor's API at scan time; the study says nothing about misuse.
How common is it per repository? Roughly 1 in every 766 Gitee repositories contained a verified-live Alibaba Cloud credential.
Is this a recent problem or legacy cruft? Mostly recent: the majority of findings were committed in the last two years, with 2025 alone contributing 12,242 unique credentials.
What did the research cost? $3,097.64 — call it $3,000 — covered by $5,000 in compute credits from Modal, over roughly one month of runtime.
Can the same approach be pointed at other sites? Yes. The Modal plus dual-scanner design transfers to most Git hosts with little more than a clone-URL substitution.
Are the leaked keys now revoked? Not confirmed. At the time of writing, revocation status for the disclosed credentials has not yet been verified.
The MyTechDailyNews take
Read as a consumer story rather than a security bulletin, the Gitee scan says something simpler: the software supply chain that ordinary users install every day is stitched together from public repositories, and the credentials embedded in them are still live months after anyone remembers putting them there. Density figures of 3.64 versus 3.11 for GitLab and 2.39 for Bitbucket are worth knowing, but the number that should change behaviour is the one that says nearly half the dataset was committed in 2025 alone. Treat a key that has touched a public repository as already spent, and check your history as well as your working tree. If you have a tip or an exposure you believe affects a widely used project, reach the MyTechDailyNews General desk at hello@techdaily.com — reporting by Tech Daily's newsroom team.