A Researcher Scanned 7.25 Million Public Gitee Repos and Found 26,400 Credentials That Still Worked. He Told the Vendors. Nobody Told the Developers.
Independent researcher Ben Zimmermann published results yesterday from about a month of scanning. He walked 7.25 million public repositories on Gitee, the Chinese code-hosting service, pulled out the credentials people had committed, and then did the step most secret-scanning research skips: he tested them.
26,400 of them still worked.
The largest single bucket is 9,473 Alibaba Cloud AccessKey pairs. The rest are mostly other cloud and AI service keys. He sent credential lists to the vendors with the most exposed keys. He did not contact the developers who leaked them, and when he published he had not confirmed that a single credential had been revoked.
Sit with that last part, because it is the whole story. Not "26,400 secrets were committed" — that is Tuesday, and every platform has a number like it. The finding is 26,400 secrets were committed, are still live, and the people who own them have not been told.
Why "still worked" is a different claim
Most secret-scanning numbers you read are pattern matches. A regex found something shaped like an AWS key in a file. That number is always enormous and always soft, because the overwhelming majority of those strings are expired, rotated, revoked, placeholder values, or test fixtures that never worked at all.
Testing changes the claim from "a string that looks like a key" to "a key." It converts a corpus statistic into an inventory of live access, and an inventory of live access is an asset — to the researcher who built it responsibly, and to anybody else who builds the same thing without that intention.
Which is the uncomfortable symmetry here. The scan is not hard. Gitee is public, the repositories are public, the pattern set is public, and the validation step is an API call per candidate. One person did this in roughly a month. Anybody with a month and worse intentions has the same 26,400 keys, and they are not sending anyone a courtesy email.
The AI keys are the part we would watch
Patrick has a name for the category this falls into: tokentheft — the theft of metered inference capacity. It deserves its own word because it does not behave like other credential theft and most programs are not set up to see it.
A stolen cloud key gets used to mine cryptocurrency or stage infrastructure, and it announces itself through a bill, an anomalous region, a spun-up instance. There are controls for that, and most cloud providers now detect the obvious cases automatically.
A stolen AI provider key gets used to make inference calls. That is it. There is no instance, no region, no new resource, no process on a host. The usage looks exactly like legitimate usage because it is the same API doing the same thing, and the only tell is volume on somebody else's invoice. We meter every single model call we make into a ledger with the price attached, and we do that because we are cheap. The security property came along for free: if our own number moves without our work moving, we would see it, and almost nobody else has that line drawn.
The economics are why this grows. Inference capacity is a liquid, resellable commodity with an immediate market. An attacker who steals a working AI key does not need to find a buyer for your data, launder anything, or build a ransom negotiation. They resell access, or run their own workload, and they do it at your rate card.
Nobody told the developers, and that is the systemic problem
Zimmermann notified vendors, not individuals. That is defensible — contacting tens of thousands of developers individually is not a thing one researcher can do, and vendors are the only parties with the standing to revoke at scale.
But it leaves the gap exactly where these things always sit, in the seam between two parties who each reasonably think the other has it. The vendor can revoke, and may or may not, on their own timeline, with their own appetite for breaking a paying customer's production system by killing a key. The developer can rotate in thirty seconds, and does not know. The researcher can tell them, and cannot, at that scale.
Most real-world security failures we find are not a missing control. They are a handoff nobody owns. This is a clean example: every party behaved reasonably and the credentials are still live.
The practical consequence for you is simple and slightly bleak: if you have ever pushed a key to a public Gitee repository, you cannot assume it has been revoked. Not because anyone was negligent, but because there is no mechanism that reliably reaches you. Go rotate it yourself.
What to actually do
Rotate on exposure, not on confirmation. A credential that has been in a public repository is burned the moment it lands, not when somebody proves it was used. The git history keeps it even after you delete the file in a later commit — removing a secret in a subsequent commit removes it from the current tree and from nothing else.
Scope every key to the smallest thing it can do. The AccessKey pairs in this dataset are the dangerous shape precisely because a cloud root-ish key does everything. An AI key that can only call inference, with a hard monthly spend ceiling, is a bad purchase for a thief.
Put a spend ceiling on every AI provider account, today. It is usually one setting, it costs nothing, and it is the only control in this post that works even when the key is already gone and you never find out. The ceiling is the difference between a surprise and a catastrophe.
Meter your own inference. Not for security theater — for the invoice. But once you have a per-call ledger, usage you did not generate becomes visible, and without one it is structurally invisible.
Scan your own history before someone else does. The tooling for this is free. If a lone researcher can validate 26,400 live keys across 7.25 million repositories in a month, your own repositories are not a hard target for anybody.
If you want our free list of infrastructure currently being used by attackers, so you can watch for traffic to it from your own estate, the IP, domain and hash feeds are at analytics.dugganusa.com/api/v1/stix-feed. No sales call, registration takes about thirty seconds, and you set the confidence floor rather than us.
A note on what we are not going to do
We are not going to go and reproduce this scan, and we would ask you not to either.
We could. The method is public and our tooling would handle it. But a second validated inventory of 26,400 live credentials makes the world more dangerous and nobody safer — the vendors already have the lists that matter, and the marginal value of our copy is zero against a real marginal risk. Holding live third-party credentials is not something we want to be doing, and "for research" does not change what the file is.
We also will not be naming any affected organization, repository or developer. The people in this dataset are victims, not threats, and we have a standing rule that exposure data never goes into our feed. We publish attacker infrastructure. A developer who committed a key to a repository in 2023 is somebody having a bad week, not an indicator.
Limits
Everything about the scan — 7.25 million repositories, 26,400 working credentials, 9,473 Alibaba Cloud AccessKey pairs, the roughly one-month duration, the vendor-only notification and the absence of confirmed revocation — is Ben Zimmermann's reported work as carried in secondary reporting today. We have not independently verified any of it, we have not seen the dataset, and we would decline it if offered.
The reporting does not give precise dates for when the credentials were tested, which means we cannot tell you how many were live today versus live at some point during a month-long scan. That is a real gap in the number and we are not going to paper over it.
The tokentheft argument is ours and it is an argument, not a measurement. We have no data on how often exposed AI keys are actually resold or abused, and anyone quoting you a rate for that should be asked how they counted it.
We have no visibility into Gitee and no relationship with it. Nothing here is a claim that Gitee is worse than any other host — the same scan against other platforms has historically found the same kind of numbers, and the reason this one is about Gitee is that this is the one somebody did.
Five percent of this is wrong somewhere. It always is.
Was this useful? Rate this post — the widget is at the bottom of the page, and we read every response. If you went and put a spend ceiling on an AI account after reading this, that is the reply we want most.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.