![\"A](\"https://images.contentstack.io/v3/assets/blt7151619cb9560896/blt91ca45d76abd18ed/6ae0b99cf59c3f199fce5dec/internal-mdb-copy-gitee-blog-draft-updated.png\")
Ben Zimmermann · MongoDB Blog · October 28, 2026
\nThis guest post by independent security researcher Ben Zimmermann was developed in collaboration with the Kingfisher team at MongoDB. Ben specializes in large-scale credential exposure research across public source-hosting platforms.
\nTL;DR: I scanned 7,256,531 public repositories on Gitee (China's largest indigenous Git hosting platform), using both TruffleHog and Kingfisher, and found 26,400 unique verified-live credentials. Findings included an active organization-admin credential for a major enterprise AI platform and thousands of live cloud provider access keys.
\nGitee, launched in 2013 by OSChina, was selected by China's Ministry of Industry and Information Technology as the country's national open-source code hosting platform. Its public API is severely constrained relative to GitHub and GitLab: no paginated projects endpoint, and the on-site code-search feature appears to have been retired years ago. A 2021 attempt to study credential exposure on Gitee concluded that its APIs were too limited to scale the research.
\nLike any large Git platform, it's an attractive surface for credential exposure:
\nGitee's public API is severely limited, so enumerating millions of repositories required combining many surfaces: 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 itself, and Gitee's internal Elasticsearch widget that backs the on-site search UI.
\nThe single official REST endpoint that returned useful data at scale was GET /api/v5/search/users?q=. I hit it with three-character prefix queries (aaa, aab, ..., zzz) and combined the results with usernames extracted from the public Explore feed (/explore/all?order=starred|popular|updated). I then expanded that set via each user's following list and the stargazers of popular repositories. This produced a seed corpus of 1,704,759 usernames.
\nWith the username corpus in hand, two per-user pages yielded repositories: gitee.com/{user}/projects (a user's own repos) and gitee.com/{user}/stared_projects (repos the user has starred). Page 1 of /projects returns full HTML; subsequent pages are AJAX-paginated (X-Requested-With: XMLHttpRequest). The stargazer-list pages used during username bootstrap paginate the same way, additionally requiring a CSRF token extracted from the page-1 HTML.
\nA large fraction of the platform sits outside the social graph. To reach it, I used the same internal Elasticsearch endpoint that backs Gitee's on-site search UI: so.gitee.com/v1/search/widget/wong1slagnlmzwvsu5ya. It takes a query ID, a q parameter, and pagination via from + size:
\nUnformatted
\nCode Snippet# elastic_scrape_repos.py\nAPI_URL = "https://so.gitee.com/v1/search/widget/wong1slagnlmzwvsu5ya"\nQUERY_ID = "1048"\nPAGE_SIZE = 20\nMAX_RESULTS = 200\nasync def fetch_page(session, username, offset=0, language=None):\nparams = {\n"query": QUERY_ID,\n"q": username,\n"from": str(offset),\n"size": str(PAGE_SIZE),\n"sort_by_f": "",\n}\nif language:\nparams["编程语言"] = language # "programming language"\nasync with session.get(\nAPI_URL,\nparams=params,\nheaders={**HEADERS, "userid": str(uuid.uuid4())},\n) as resp:\nresp.raise_for_status()\nreturn await resp.json()
\nEach query returned at most 20 results per page, with a hard cap of 200 results total (from + size <= MAX_RESULTS) regardless of how many matches actually existed. For specific usernames, this was usually fine; for common usernames and trigram prefix queries against the widget, the cap silently truncated results.
\nThe widget's response includes Elasticsearch aggregations that bucket results by language (编程语言) and license (许可证). For the per-username scrape, when a query was capped, I split it by the language buckets the response already returned:
\nUnformatted
\nCode Snippet# elastic_scrape_repos.py\nMAX_RESULTS = 200\nPAGE_SIZE = 20\ndef get_total(data):\ntotal = data.get("hits", {}).get("total", {})\nreturn total.get("value", 0), total.get("relation", "eq")\ndef get_language_buckets(data):\naggs = data.get("aggregations", {})\nreturn [b["key"] for b in aggs.get("编程语言", {}).get("buckets", [])]
\ntotal, relation = get_total(data)\nif total <= PAGE_SIZE:\nreturn all_records
\nif not (total >= MAX_RESULTS and relation == "gte"):\nfor offset in range(PAGE_SIZE, min(total, MAX_RESULTS), PAGE_SIZE):\ndata = await fetch_page(session, username, offset=offset)\ncollect(parse_hits(data, username))\nreturn all_records
\nfor lang in get_language_buckets(data):\noffset = 0\nwhile offset < MAX_RESULTS:\ndata = await fetch_page(session, username, offset=offset, language=lang)\nhits = parse_hits(data, username)\ncollect(hits)\nif len(hits) < PAGE_SIZE:\nbreak\noffset += PAGE_SIZE
\nFor trigram prefix queries against the widget (used to surface repos not associated with any user I'd discovered), I extended this into a BFS over a query tree: capped nodes split first by language, then by license, then by deeper prefix until each branch fit within 200 results.
\nAfter deduplicating repo IDs across all sources, this produced a working set of 7,256,531 unique public Gitee repositories.
\nThe next challenge was cloning and scanning the 7.25 million repositories. To do this in a single Python script, I used Modal, a serverless compute platform popular for AI workloads but well-suited to most parallel jobs. I ran TruffleHog and Kingfisher concurrently against every repository for increased coverage. Each surface verified credentials that the other missed, so running both caught more exposed credentials than either alone.
\nFigure 1. Dual-scanner pipeline architecture.
\nThe container image is a multi-stage build that pulls both scanner binaries from their upstream releases into a single Python base, plus git and OpenSSH for cloning:
\nUnformatted
\nCode SnippetFROM trufflesecurity/trufflehog:latest AS trufflehog\nFROM ghcr.io/mongodb/kingfisher:latest AS kingfisher\nFROM python:3.11-slim\nCOPY --from=trufflehog /usr/bin/trufflehog /usr/local/bin/trufflehog\nCOPY --from=kingfisher /usr/local/bin/kingfisher /usr/local/bin/kingfisher\nRUN apt-get update && apt-get install -y git openssh-client
\n&& rm -rf /var/lib/apt/lists/*
A single Modal function bare-clones each repo over SSH and runs both scanners concurrently as subprocesses against the same on-disk clone:
\nUnformatted
\nCode Snippet@app.function(\nimage=image,\nvolumes={"/findings": volume},\ntimeout=300,\ncpu=(0.125, 2.0),\nmemory=(256, 4096),\nmax_containers=350,\n)\ndef scan(repo_url: str):\nrepo_name = repo_url.rstrip("/").split("/")[-1].removesuffix(".git")\nclone_path = f"/tmp/{repo_name}.git"\nssh_url = repo_url.replace("https://gitee.com/", "git@gitee.com:")\nsubprocess.run(\n["git", "clone", "--bare", "--quiet", ssh_url, clone_path],\ncapture_output=True, check=True,\n)\nth_proc = subprocess.Popen([\n"trufflehog", "git", "--bare", f"file://{clone_path}",\n"--json", "--only-verified", "--allow-verification-overlap",\n], stdout=subprocess.PIPE, text=True)\nkf_proc = subprocess.Popen([\n"kingfisher", "scan", clone_path,\n"--format", "jsonl", "--only-valid",\n], stdout=subprocess.PIPE, text=True)\nth_output = th_proc.communicate()[0].strip()\nkf_output = kf_proc.communicate()[0].strip()
\nI split the corpus into 50 batches of ~150K repos and ran them sequentially at a steady 350 concurrent containers. Smaller batches were safer at this scale and easier to resume after interruptions; running larger batches was unstable and would hit clone-side blocks.
\nTotal wall time: roughly one month of continuous execution. Per-repo clone times were a major contributor: Gitee's servers sit in China, and cross-Pacific network distance plus SSH protocol overhead made each clone materially slower than an equivalent GitHub clone would be. The total cost was $3,097.64, fully absorbed by the $5,000 compute-credit sponsorship from Modal that supported this research. The same Modal + dual-scanner architecture works against most Git hosts with little more than a clone-URL substitution. I used a smaller-scale version of this approach in a prior investigation of Algolia DocSearch admin keys.
\nAcross the 7,256,531 public Gitee repositories scanned, the dual-scanner pipeline surfaced 26,400 unique, verified-live credentials after deduplicating by token value.
\nBoth scanners authenticate each candidate against its vendor's API at scan time (TruffleHog's --only-verified and Kingfisher's --only-valid modes), discarding anything that pattern-matches but fails to authenticate. The 26,400 figure is deduplicated by raw secret value, so duplicates across repositories or scanners count once.
\n| Scanner | Unique Findings |
|---|---|
| TruffleHog | 12,737 |
| Kingfisher | 14,664 |
| Caught by both | 1,001 |
| Total unique credentials | 26,400 |
Either scanner alone would have caught only about half of these credentials. The two tools' detector coverage was largely complementary: TruffleHog dominated Alibaba Cloud key detection (9,428 vs. 993), while Kingfisher dominated DeepSeek (2,940 vs. 230), OpenAI (1,198 vs. 150), HuggingFace (154 vs. 1), and Chinese-AI services like Zhipu (1,489 vs. 0) that TruffleHog has no detector for.
\nThe single most common leaked credential type was Alibaba Cloud AccessKey pairs: roughly 1 in every 766 Gitee repositories contained a verified-live Alibaba Cloud credential.
\nFigure 2. Credentials by vendor.
\n![\"A](\"https://images.contentstack.io/v3/assets/blt7151619cb9560896/blt31af8a3bc3afccd4/6ae0bc6109de0e19ab7ad120/figure3.png\")
A long tail of additional vendors (LangSmith, OpenWeather, Algolia, PostHog, OpenRouter, MySQL, Stripe, Slack, Twitter, and others) accounts for the rest.
\nThe vast majority of verified-live credentials were committed in the last two years. 2025 alone accounts for 12,242 unique credentials, nearly half the entire dataset.
\nFigure 3. Unique credentials committed by year.
\n![\"A](\"https://images.contentstack.io/v3/assets/blt7151619cb9560896/bltfbc653e59fa14cad/6ae0bd2d332c2f7b0ca5d929/figure4.png\")
Most credentials were committed from personal mail services (qq.com, 163.com, gmail.com), making per-company attribution impossible at scale. The corporate-domain numbers below are a floor; even so, the names span major Chinese and Western tech companies alike.
\nFigure 5. Unique credentials by committer email domain.
\n![\"A](\"https://images.contentstack.io/v3/assets/blt7151619cb9560896/blt1b8175fe75482468/6ae0bdd21a8b5a0e7477135d/figure5.png\")
Smaller corporate footprints also appear from Oracle, Apple, Meta, Anthropic, and others, plus Chinese commercial and academic domains.
\nThe closest prior data points come from TruffleSecurity's scan of 5.6 million public GitLab repositories, and a companion Bitbucket scan referenced in that post.
\n| Platform | Repos scanned | Verified-live credentials | Per 1K 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 tops both Western platforms on raw count and per-repository density. One methodology note: the TruffleSecurity scans used TruffleHog alone, while this one used TruffleHog and Kingfisher together. TruffleHog's detector library skews toward Western vendors, and Gitee has heavy Chinese-vendor activity (Alibaba Cloud, DeepSeek, Zhipu, and others) that Kingfisher's coverage helps to surface; stripping our findings to TruffleHog-only puts Gitee at 1.76 per 1,000 repos.
\nI emailed the vendors with the highest exposure volume in this scan, providing each a coordinated report containing the full list of verified-live credentials associated with their service, along with source-repository metadata to help them attribute affected customers.
\nPer-developer notification (contacting the committer of each leaked credential individually) was not pursued at this scale. Vendor-side revocation is the more reliable path, since it doesn't require any action from the user who leaked the credential.
\nAt the time of writing, revocation status for the disclosed credentials has not yet been confirmed.
\nOriginally published at the MongoDB Blog.
","headings":[{"level":2,"text":"What is Gitee?","id":"what-is-gitee"},{"level":2,"text":"Enumerating millions of Gitee repositories","id":"enumerating-millions-of-gitee-repositories"},{"level":3,"text":"Bootstrapping a username corpus","id":"bootstrapping-a-username-corpus"},{"level":3,"text":"Scraping per-user pages on the frontend","id":"scraping-per-user-pages-on-the-frontend"},{"level":3,"text":"Querying the on-site search widget","id":"querying-the-on-site-search-widget"},{"level":3,"text":"Escaping the 200-result cap with bucket splitting","id":"escaping-the-200-result-cap-with-bucket-splitting"},{"level":1,"text":"After fetching page 1 for a username:","id":"after-fetching-page-1-for-a-username"},{"level":1,"text":"Within the cap: paginate normally","id":"within-the-cap-paginate-normally"},{"level":1,"text":"Capped: split by language buckets that Elastic already returned","id":"capped-split-by-language-buckets-that-elastic-already-returned"},{"level":2,"text":"Wiring up the scan pipeline","id":"wiring-up-the-scan-pipeline"},{"level":3,"text":"The Docker image","id":"the-docker-image"},{"level":3,"text":"The per-repo scan function","id":"the-per-repo-scan-function"},{"level":1,"text":"... write hits to the shared findings volume","id":"write-hits-to-the-shared-findings-volume"},{"level":3,"text":"Dispatching 7.25M repos in batches","id":"dispatching-7-25m-repos-in-batches"},{"level":3,"text":"Cost and scale","id":"cost-and-scale"},{"level":2,"text":"The results","id":"the-results"},{"level":3,"text":"Secrets by type","id":"secrets-by-type"},{"level":3,"text":"Secrets committed by date","id":"secrets-committed-by-date"},{"level":3,"text":"Secrets by committer email domain","id":"secrets-by-committer-email-domain"},{"level":3,"text":"Comparing Gitee with GitLab and Bitbucket","id":"comparing-gitee-with-gitlab-and-bitbucket"},{"level":2,"text":"Disclosure","id":"disclosure"},{"level":2,"text":"Summary","id":"summary"}]}}