Like any large Git platform, it's an attractive surface for credential exposure:

• It is Git-based, so secrets buried deep in commit history persist.
• 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.

Enumerating millions of Gitee repositories

Gitee'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.

Bootstrapping a username corpus

The 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.

Scraping per-user pages on the frontend

With 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.

Querying the on-site search widget

A 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:

Unformatted

Code Snippet# elastic_scrape_repos.py API_URL = "https://so.gitee.com/v1/search/widget/wong1slagnlmzwvsu5ya" QUERY_ID = "1048" PAGE_SIZE = 20 MAX_RESULTS = 200 async def fetch_page(session, username, offset=0, language=None): params = { "query": QUERY_ID, "q": username, "from": str(offset), "size": str(PAGE_SIZE), "sort_by_f": "", } if language: params["编程语言"] = language # "programming language" async with session.get( API_URL, params=params, headers={**HEADERS, "userid": str(uuid.uuid4())}, ) as resp: resp.raise_for_status() return await resp.json()

Each 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.

Escaping the 200-result cap with bucket splitting

The 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:

Unformatted

Code Snippet# elastic_scrape_repos.py MAX_RESULTS = 200 PAGE_SIZE = 20 def get_total(data): total = data.get("hits", {}).get("total", {}) return total.get("value", 0), total.get("relation", "eq") def get_language_buckets(data): aggs = data.get("aggregations", {}) return [b["key"] for b in aggs.get("编程语言", {}).get("buckets", [])]

After fetching page 1 for a username:

total, relation = get_total(data) if total <= PAGE_SIZE: return all_records

Within the cap: paginate normally

if not (total >= MAX_RESULTS and relation == "gte"): for offset in range(PAGE_SIZE, min(total, MAX_RESULTS), PAGE_SIZE): data = await fetch_page(session, username, offset=offset) collect(parse_hits(data, username)) return all_records

Capped: split by language buckets that Elastic already returned

for lang in get_language_buckets(data): offset = 0 while offset < MAX_RESULTS: data = await fetch_page(session, username, offset=offset, language=lang) hits = parse_hits(data, username) collect(hits) if len(hits) < PAGE_SIZE: break offset += PAGE_SIZE

For 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.

After deduplicating repo IDs across all sources, this produced a working set of 7,256,531 unique public Gitee repositories.

Wiring up the scan pipeline

The 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.

Figure 1. Dual-scanner pipeline architecture.

The Docker image

The 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:

Unformatted

Code SnippetFROM trufflesecurity/trufflehog:latest AS trufflehog FROM ghcr.io/mongodb/kingfisher:latest AS kingfisher FROM python:3.11-slim COPY --from=trufflehog /usr/bin/trufflehog /usr/local/bin/trufflehog COPY --from=kingfisher /usr/local/bin/kingfisher /usr/local/bin/kingfisher RUN apt-get update && apt-get install -y git openssh-client
&& rm -rf /var/lib/apt/lists/*

The per-repo scan function

A single Modal function bare-clones each repo over SSH and runs both scanners concurrently as subprocesses against the same on-disk clone:

Unformatted

Code Snippet@app.function( image=image, volumes={"/findings": volume}, timeout=300, cpu=(0.125, 2.0), memory=(256, 4096), max_containers=350, ) def scan(repo_url: str): repo_name = repo_url.rstrip("/").split("/")[-1].removesuffix(".git") clone_path = f"/tmp/{repo_name}.git" ssh_url = repo_url.replace("https://gitee.com/", "git@gitee.com:") subprocess.run( ["git", "clone", "--bare", "--quiet", ssh_url, clone_path], capture_output=True, check=True, ) th_proc = subprocess.Popen([ "trufflehog", "git", "--bare", f"file://{clone_path}", "--json", "--only-verified", "--allow-verification-overlap", ], stdout=subprocess.PIPE, text=True) kf_proc = subprocess.Popen([ "kingfisher", "scan", clone_path, "--format", "jsonl", "--only-valid", ], stdout=subprocess.PIPE, text=True) th_output = th_proc.communicate()[0].strip() kf_output = kf_proc.communicate()[0].strip()

... write hits to the shared findings volume

Dispatching 7.25M repos in batches

I 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.

Cost and scale

Total 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.

The results

Across the 7,256,531 public Gitee repositories scanned, the dual-scanner pipeline surfaced 26,400 unique, verified-live credentials after deduplicating by token value.

Both 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.

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.

Secrets by type

The 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.

Figure 2. Credentials by vendor.

A long tail of additional vendors (LangSmith, OpenWeather, Algolia, PostHog, OpenRouter, MySQL, Stripe, Slack, Twitter, and others) accounts for the rest.

Secrets committed by date

The 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.

Figure 3. Unique credentials committed by year.

Secrets by committer email domain

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.

Figure 5. Unique credentials by committer email domain.

Smaller corporate footprints also appear from Oracle, Apple, Meta, Anthropic, and others, plus Chinese commercial and academic domains.

Comparing Gitee with GitLab and Bitbucket

The 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.

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.

Disclosure

I 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.

Per-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.

At the time of writing, revocation status for the disclosed credentials has not yet been confirmed.

Summary

• Gitee is a meaningful credential-exposure surface. 26,400 verified-live credentials across 7.25M repositories. Per-repository density higher than comparable published scans of GitLab and Bitbucket.
• Major tech companies appear in the committer metadata, Chinese and Western alike. The breadth includes Huawei, ByteDance, Google, Microsoft, Oracle, and others, suggesting this is not a purely-Chinese-developer phenomenon.
• Disclosure paths are asymmetric. Western companies typically have bug bounty programs or accessible security channels. Most Chinese companies don't, leaving leaked credentials without a clear remediation path.
• The architecture is portable. The same Modal + dual-scanner pipeline works on most Git hosts with little more than a clone-URL substitution; the full scan cost roughly $3,000.

---

Originally published at the MongoDB Blog.