Identity

Gitee scan: 26,400 live keys, and one scanner finds half

By Yaali. November 1, 2026, 6 min read, Identity, Threat intel.

A scan of 7.25 million public Gitee repos found 26,400 working keys, mostly Alibaba Cloud. Each scanner missed about half. How to find, revoke and check yours.

Independent researcher Ben Zimmermann scanned 7,256,531 public repositories on Gitee, China's largest Git hosting platform, and found 26,400 unique credentials that still authenticated. He published the results on October 28 on MongoDB's blog, written with the team behind Kingfisher, MongoDB's open source secret scanner. The most common find was Alibaba Cloud AccessKey pairs, followed by YouTube API keys and keys for AI services such as DeepSeek, Zhipu and OpenAI. One was an organization admin credential for a major enterprise AI platform, which the report does not name.

If your developers, contractors or suppliers push code to Gitee, or you hold Alibaba Cloud or Chinese AI provider accounts, some of these keys could be yours. The finding that matters for everyone else is about tooling: Zimmermann ran two scanners over the same repositories, and they agreed on only 1,001 credentials. A team running one of them would have missed about half of what was there.

How a public repository ends up holding a working key

A credential lands in a repository the same way on every host. A developer pastes an API key into a config file to test something, commits it, and the commit is pushed to a public repository. Deleting the file later only adds a new commit; the old one stays in the history, and every clone and fork keeps a copy.

Whether the key keeps working depends on the issuer. Some providers watch public code and revoke their own tokens when they appear there. The report notes that Gitee has no public equivalent of the secret scanning partnerships GitHub runs with token issuers, so a key pushed there is less likely to be found and killed by its vendor. That fits the numbers: Gitee came out at 3.64 live credentials per 1,000 repositories, against 3.11 in an earlier Truffle Security scan of GitLab and 2.39 on Bitbucket.

Those rates are not a like-for-like comparison, and the report says so. The GitLab and Bitbucket scans used TruffleHog alone. Counting only TruffleHog findings, Gitee drops to 1.76 per 1,000 repositories, below both. The fair reading is that every public host leaks live keys at a similar order of magnitude, and that the number you get depends on the scanner.

The leaks are also recent. Of the 26,400 credentials, 12,242 were committed in 2025, nearly half the dataset. Most of the exposure comes from the last two years of commits, even though some keys date back to the late 2000s.

Two scanners, two different answers

Both tools check each candidate against the issuing service at scan time, so every finding was a key that actually worked. TruffleHog reported 12,737 live credentials and Kingfisher 14,664. Only 1,001 appeared in both results.

The gap comes from detectors. A scanner can only verify a key type it has a detector for, meaning a pattern to recognise the key plus code that calls the vendor's API to test it. TruffleHog has no detector for Zhipu BigModel keys, so all 1,489 Zhipu keys in the study came from Kingfisher. According to the report, TruffleHog found most of the Alibaba Cloud keys, while Kingfisher found most of the DeepSeek and OpenAI keys.

The 9,473 Alibaba Cloud AccessKey pairs work out to one live Alibaba key for every 766 repositories scanned. An AccessKey pair is an ID and a secret that sign API calls as a RAM (Resource Access Management) user or as the account itself, so a leaked pair can do whatever its owner's permissions allow. The AI keys carry a different risk: someone else's usage billed to your account, and access to whatever files or fine-tuned models sit in it.

Zimmermann sent each of the most exposed vendors the full list of live credentials for their service, with the source repositories. He did not contact individual developers. When the report went out, he had not confirmed that any of the keys had been revoked.

What to do

1. Scan with two tools, history included. Clone each repository you or your suppliers publish, on Gitee or anywhere else, and run both verifying scanners. With TruffleHog: trufflehog git file://path/to/repo --results=verified. With Kingfisher: kingfisher scan /path/to/repo --only-valid, which includes the Git history by default. Gitleaks (gitleaks git -v path/to/repo) is a useful third pass for formats neither tool can verify, but it matches patterns and entropy and does not test whether a key works, so expect noise.
2. Revoke first. For an Alibaba Cloud key, open the RAM console, go to the user's details page and check the last used time of the leaked AccessKey. A RAM user can hold two active pairs, so create the new one, move your applications to it, then disable the old one. Calls with a disabled key fail with a 403 error, and you can still re-enable it if something breaks. Delete it once nothing depends on it. For a YouTube key, regenerate or delete it in the Google Cloud console under APIs and Services, Credentials. For DeepSeek, Zhipu and OpenAI, delete the key in the provider's dashboard and issue a new one.
3. Check what the key did. In the ActionTrail console, open AccessKey Pair Audit, then AccessKey Event Query, and enter the AccessKey ID. It lists the services, API events, source IP addresses and resources the key touched over the last 90 days. Look for new RAM users, policy changes, deleted resources and bucket permission changes, and check the billing console for charges you do not recognise. Alibaba notes that ActionTrail does not record data plane calls such as OSS object uploads by default. For a leaked AWS key, filter CloudTrail Event history by the access key ID. For AI keys, read the usage page for spend from days or models you did not use.
4. Then clean the history. Once the key is dead, remove it from the repository with git filter-repo and force-push, so it stops showing up in your own scans. Doing this before revocation gains nothing, because forks and existing clones still hold the old commit.
5. Stop the next one at the developer's machine. Push protection on GitHub only covers GitHub. A pre-commit hook works on any host: Gitleaks and TruffleHog both publish hooks for the pre-commit framework, and Kingfisher ships a .pre-commit-hooks.yaml in its repository. Move workloads off long-lived AccessKeys to temporary credentials from STS (Security Token Service), which Alibaba recommends, and give each remaining key its own least-privilege RAM user.

Pick scanners by the keys you actually use

This study is a direct test of scanner coverage, and the overlap shows that one popular tool reported less than half of the live keys. Check the detector list of whatever you run in CI against the providers your teams use. If you use Chinese AI providers or Alibaba Cloud, confirm there are detectors for those formats, and run a second scanner on a schedule against full history.

Finding keys in code and history is part of our red team code review, and moving workloads from static keys to short-lived credentials is part of our cloud and Kubernetes security work. To find out what your organization has left in public repositories, open the chat and Yaali, our AI agent, will pass your question to an engineer.

Sources: MongoDB Blog, Ben Zimmermann, The Hacker News, RuntimeWire, Alibaba Cloud, AccessKey leak response, Alibaba Cloud, rotate AccessKey pairs, Alibaba Cloud, ActionTrail AccessKey query, Kingfisher, TruffleHog, Gitleaks.