26,400 Active Cloud and AI Keys Exposed in China's Gitee Repositories

A credential removed from public code can remain usable if nobody revokes it. On China's Gitee platform, a scan uncovered 26,400 cloud and AI keys that authenticated during testing.

Independent researcher Ben Zimmermann published the findings Oct. 28 after examining 7.25 million public repositories. Credentials included Alibaba Cloud, DeepSeek, and international services. The scan did not establish attacker use or continued validity today.

For Chinese developers and APAC businesses working with regional suppliers, exposed code could also mean exposed cloud accounts or AI services.

Thousands of working keys were buried in Git histories

In research with MongoDB's Kingfisher team, Zimmermann ran TruffleHog and Kingfisher against full repository histories. Both scanners checked suspected credentials with the issuing provider and counted each working key once. Deleting a secret from current code does not erase older commits.

The discoveries included an organization-admin credential for an unnamed enterprise AI platform. A working key does not always grant administrative access: Google's standard API keys identify projects for quotas and billing, and the risks depend on their restrictions.

China's Gitee ecosystem connects regional developers to global services

Chosen to support China's national open-source hosting initiative, Gitee says it has more than 14 million members and 40 million projects. The study examined 7.25 million public repositories, not every hosted project.

Exposed Alibaba Cloud, DeepSeek, or Zhipu keys could enable unauthorized usage and charges, depending on permissions. The risk also crosses borders: a contractor's Gitee repository may contain keys for applications operated elsewhere in APAC. Businesses should therefore review suppliers' Gitee projects even if their own code is hosted elsewhere.

Zimmermann found many commits associated with personal email services, making ownership difficult to determine. Gitee's location does not establish how many affected organizations are Chinese or prove that any named company's systems were compromised.

Two scanners exposed different security blind spots

TruffleHog identified 12,737 working credentials and Kingfisher 14,664, with only 1,001 overlapping. Kingfisher found all 1,489 Zhipu keys because TruffleHog lacked a detector, and far more DeepSeek keys (2,940 versus 230). TruffleHog performed better on Alibaba Cloud.

Nearly half the findings, 12,242 keys, came from 2025 commits. For Chinese AI teams, these gaps show why relying on one scanner or checking only current source files could leave exposed credentials undetected.

The Hacker News noted that the exact dates of the month-long scan were not disclosed. Zimmermann notified major affected vendors, but individual developers were not contacted, and revocation remained unconfirmed. A vendor alert should not be mistaken for a completed fix.

Chinese developers and APAC businesses need to investigate exposed access

Organizations should first identify who owns each exposed key and which applications depend on it. Deleting code cannot invalidate a copied credential, so teams need to address the underlying access at its provider.

• Developers and Chinese contractors: Search old Gitee commits, forks, and shared projects. Confirm scanners recognize Alibaba Cloud, DeepSeek, and Zhipu keys, then store replacements outside source code.
• Cloud administrators: Follow Alibaba Cloud's instructions to replace AccessKeys in applications before disabling old ones. Review ActionTrail's last 90 days for unusual API calls and new users; check OSS and SLS service logs separately.
• AI platform owners: Revoke exposed API keys, review usage and charges, and apply available limits and restrictions. OpenAI recommends separate keys, spending controls, and checks before publishing code.

APAC companies with China-based suppliers should request evidence of repository scans, revoked keys, and activity reviews. Include CI/CD scripts, mirrored repositories, and shared development projects in that check. With revocation across the study unverified, an incident is not resolved simply because the offending line of code has disappeared.

Also read: Thousands of leaked AWS access keys remain active, highlighting why companies need to revoke exposed credentials rather than simply remove them from public repositories.