26,400 Live Cloud and AI Credentials Found in Public Gitee Repositories

A single scan of a Chinese code-hosting platform has surfaced tens of thousands of secrets that were not just leaked—they were still working. Independent researcher Ben Zimmermann reported on October 28 that he discovered 26,400 valid cloud and AI credentials left in public repositories on Gitee, one of China's largest source-code hosting services. The findings, first covered by The Hacker News, underscore a stubborn problem in software development: secrets committed to public code rarely get cleaned up, and when they do, the underlying keys are often never revoked.

How the discovery unfolded

The research involved scanning 7.25 million public Gitee repositories. Rather than simply flagging strings that looked like API keys, Zimmermann tested whether the credentials still functioned. That distinction matters enormously. A leaked but deactivated key is a hygiene failure; a leaked key that still authenticates is an active exposure that anyone who copied it could have exploited.

Of the credentials that remained valid, the bulk were keys for cloud and AI services. The concentration in AI tooling reflects how quickly organizations have adopted large language model platforms and the API-key-based access model that dominates that ecosystem. These keys frequently carry billing implications, data access rights, or both—making them attractive to attackers who want free compute, model access, or a foothold into a victim's data pipeline.

Why public repositories keep leaking secrets

Credential leakage through version control is not a new phenomenon, but it persists for predictable reasons. Developers hardcode keys during prototyping and forget to remove them. Configuration files intended for local use get committed alongside application code. Tutorials and sample projects, often forked and modified, carry example credentials that someone later replaced with real ones. Once a secret enters commit history, deleting the file in a later commit does not remove it—the key remains recoverable from the repository's past.

The Gitee findings also highlight a regional dimension. Much of the public reporting and tooling around secret scanning has focused on Western platforms such as GitHub. Gitee's scale—millions of public repositories—makes it a comparable attack surface, and researchers and defenders alike may have paid it less attention.

The AI key problem

Credentials for AI services deserve particular scrutiny. Many providers issue long-lived API keys with broad permissions and offer limited granular scoping. A leaked key can translate into unauthorized usage billed to the owner, exposure of prompts and potentially sensitive data passed through the API, and in some configurations access to fine-tuning datasets or stored artifacts. Because AI services are often adopted outside formal procurement and security review, these keys may not appear in the asset inventories that security teams monitor.

What defenders should take away

• Treat every committed secret as compromised. Rotate first, investigate second. Removing the file from the current branch is not remediation.
• Scan history, not just the working tree. Automated secret scanning should cover full commit history and run in pre-commit hooks and CI pipelines.
• Inventory AI and SaaS credentials. Shadow adoption of AI platforms means keys can exist outside normal credential management. Discover them, scope them narrowly, and set expiration.
• Use short-lived, scoped credentials where providers support it. Prefer workload identity or token exchange over static keys.
• Monitor for anomalous usage. Unusual spend, geography, or request patterns on cloud and AI accounts can signal misuse of a leaked key.
• Educate contributors. Many leaks originate with developers who do not realize that public means public—and permanent.

The bigger picture

The Gitee research is a reminder that credential exposure is less an exotic vulnerability than a chronic condition. Scanning millions of repositories and validating what turns up is a simple methodology, yet it produced a large yield of live secrets. Organizations cannot assume that because a repository is obscure, or hosted on a platform outside their usual threat model, their keys are safe. Public code is indexed, cloned, and scraped continuously. The only reliable defense is to assume exposure is possible and design credential lifecycles—short lifetimes, least privilege, automated rotation—that limit the damage when it happens.

For security teams, the practical next step is straightforward: run a validated secret scan across your own repositories and those of your vendors, and rotate anything that still works.