Independent researcher **Ben Zimmermann** conducted an extensive scan of 7.25 million public **Gitee** repositories, revealing a substantial cache of exposed and still-active credentials. His findings, detailed in a report published on October 28, highlight a critical security oversight by developers. Zimmermann utilized two secret scanners, **TruffleHog** and **Kingfisher**, to identify and validate these credentials against their respective services. The scan not only identified current exposures but also unearthed credentials from the full commit history, meaning even keys subsequently removed from active code could still be retrieved and exploited.  ### Scope of the Exposure Out of the 26,400 unique working credentials discovered, nearly half (12,242) originated from 2025 by commit date, with some dating back to the late 2000s. The most common exposures included: * 9,473 **Alibaba Cloud AccessKey** pairs * 3,805 **YouTube API** keys * 3,170 **DeepSeek** keys * 1,489 keys for **Zhipu's BigModel AI** platform * 1,348 **OpenAI** keys Smaller numbers of credentials for services like **GitHub**, **AWS**, **Google Cloud**, and **Google's Gemini** were also identified. Notably, one active organization-admin credential for a major enterprise AI platform was found, though its specific capabilities were not disclosed. ### Potential Impact of Compromised Keys The implications of a leaked key vary by service. **OpenAI**, for instance, warns that a compromised key can lead to unauthorized usage of an account's quota, resulting in unexpected charges, data loss, and interrupted API access. Similarly, an unrestricted **Google Cloud** API key, which includes **YouTube API** keys, could potentially be used across any API that accepts such credentials.  ### Remediation for Exposed Credentials Security professionals and developers are strongly advised to treat any key ever committed to a public **Gitee** repository as compromised and to revoke it immediately. Deleting a key from code or rewriting repository history is insufficient, as the key persists in the commit history. Specific actions recommended by providers include: * **Alibaba Cloud:** Create a new **AccessKey** pair, migrate applications, then disable and delete the old pair. Monitor **ActionTrail** for suspicious API calls and service-specific logs for data operations. * **Google and YouTube API keys:** Rotate the key to generate a new one with existing restrictions, update applications, and then delete the old key. Implement API restrictions to limit key functionality. * **OpenAI:** Immediately rotate the key via the API Keys page and set spend limits to mitigate financial impact from unauthorized usage. ### Scanner Performance and Platform Comparison **Zimmermann's** analysis, developed in conjunction with the **Kingfisher** team at **MongoDB**, highlighted the benefits of using multiple scanning tools. While **TruffleHog** found 12,737 working credentials, **Kingfisher** identified 14,664, with only 1,001 overlapping results. This discrepancy underscores that relying on a single scanner may leave significant vulnerabilities undetected, especially if the tool lacks detectors for specific services. Comparatively, **Gitee** exhibited a higher rate of exposed working credentials (3.64 per 1,000 repositories) than previous scans of **GitLab** (3.11) and **Bitbucket** (2.39) when using **TruffleHog** alone. However, due to differences in scanner coverage, a direct comparison of overall security posture between platforms remains complex. This incident serves as a stark reminder of the persistent challenge of credential management in public code repositories and the ongoing need for robust secret scanning practices.