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

A scan of more than 7.2 million public repositories on Gitee, China's largest indigenous Git hosting platform, uncovered 26,400 unique credentials that were still working when tested, most of them keys for cloud and AI services including Alibaba Cloud, DeepSeek, OpenAI and Zhipu's BigModel platform. Independent security researcher Ben Zimmermann published the results on October 28, 2026, in a guest post developed with MongoDB's Kingfisher team; The Hacker News covered the research on October 29, 2026, in a report by Swati Khandelwal. Zimmermann scanned 7,256,531 public repositories over roughly one month, with exact scan dates not disclosed, validating every candidate secret against its issuing service to confirm it was live rather than stale. The scan drew on a seed corpus of 1,704,759 usernames to enumerate candidate repositories across the platform.

What was the specific vulnerability?

The vulnerability is secret leakage: developers pushed live API keys and access credentials into public Gitee repositories, where anyone could read them and use them against the issuing services. According to The Hacker News, the verified-live credentials included 9,473 Alibaba Cloud AccessKey pairs, 3,805 YouTube API keys, 3,170 DeepSeek keys, 1,489 Zhipu BigModel AI platform keys and 1,348 OpenAI keys, with smaller numbers for GitHub, AWS, Google Cloud and Google's Gemini. Zimmermann also reported finding, in his words, "an active organization-admin credential for a major enterprise AI platform"; he did not name the platform or describe what it could reach. Gitee, launched in 2013 by OSChina and designated in 2020 by China's Ministry of Industry and Information Technology as the national open-source code-hosting platform, produced a leak rate of 3.64 working credentials per 1,000 repositories scanned, higher than earlier scans of GitLab (3.11 per 1,000) and Bitbucket (2.39 per 1,000). The concentration of AI-service keys, more than 6,000 across DeepSeek, Zhipu BigModel, OpenAI and Gemini, reflects how frequently developers hardcode model API keys into application code and commit them alongside it.

How was the incident detected?

The exposure was found by Zimmermann during a manual research scan using two secret scanners, TruffleHog from Truffle Security and Kingfisher from MongoDB, run over every repository's full commit history rather than only the latest snapshot of the code. Each credential the tools flagged was validated against its issuing service to confirm it still worked, which is what distinguishes the 26,400 figure from a count of mere string matches. The two scanners overlapped far less than expected: TruffleHog found 12,737 working credentials, Kingfisher found 14,664, but only 1,001 were found by both, meaning each tool alone caught roughly half the total. According to the MongoDB blog post, Kingfisher found all 1,489 Zhipu BigModel keys because TruffleHog has no detector for that platform, a gap that illustrates how detector coverage varies between tools. Zimmermann published the full methodology and results on the MongoDB blog on October 28, 2026, and the findings received independent coverage the following day.

What is the current impact?

The impact is unremediated: as of publication on October 28, 2026, Zimmermann had not confirmed that any of the 26,400 credentials had been revoked. He notified the vendors with the most exposed keys but did not contact the individual developers whose repositories leaked them, so the working keys remained available to anyone reading public code. The exposure spans both recent and old commits: 12,242 of the credentials, nearly half the total, came from commits dated 2025, while some dated back to the late 2000s, meaning some keys had remained live for close to two decades. OpenAI's guidance, quoted in the coverage, states that a compromised key lets another person use the account's quota without consent, causing "data loss, unexpected charges," a used-up monthly quota and interrupted API access. Because the keys were verified live rather than merely present, anyone who copied one from a public repository could have used it against the associated cloud or AI account, and the vendor notifications do not by themselves disable any key, since revocation must be performed by each credential's owner.

What are the next steps?

The immediate step for affected developers is manual revocation: anyone who ever pushed a key to a public Gitee repository must treat it as exposed and rotate it, because deleting the key from code or rewriting Git history does not revoke it, per Truffle Security. Remediation differs by provider. Alibaba Cloud AccessKeys require replacement through the account's key management console, after which the old pair stops working. Google API keys should be rotated with API restrictions applied to limit what a leaked key can call. OpenAI recommends rotating the key and adding spend limits to cap the financial damage of unauthorized use. Organizations should also scan their own repositories' full commit histories with secret-scanning tools, since the Zimmermann results show that no single scanner catches everything and that credentials can remain live for years after being committed. Vendors notified by the researcher face their own follow-up: identifying affected accounts and forcing rotations where account holders cannot be reached.

By the numbers

Source snapshot