Follow us on Google News
More than 26,000 valid cloud and artificial intelligence credentials were found exposed in publicly accessible repositories on Gitee, raising fresh concerns over how developers handle API keys and other sensitive secrets in source code.
Independent researcher Ben Zimmermann identified 26,400 working credentials after scanning 7.25 million public repositories hosted on Gitee, a major Chinese code-hosting platform. The findings were published on October 28.
The exposed credentials included keys linked to major cloud and AI platforms such as Alibaba Cloud, DeepSeek, OpenAI, YouTube, Google Cloud, GitHub and Amazon Web Services.
What made the findings particularly serious was that the credentials were not merely present in source code. They were still valid when tested by the scanning tools used during the research.
Alibaba Cloud Keys Made Up Largest Share
The largest group consisted of 9,473 Alibaba Cloud AccessKey pairs.
Researchers also identified 3,805 YouTube API keys, 3,170 DeepSeek keys, 1,489 credentials associated with Zhipu’s BigModel AI platform and 1,348 OpenAI keys.
Smaller numbers of working credentials linked to GitHub, AWS, Google Cloud and Google’s Gemini platform were also found.
One exposed credential was described as an active organisation-admin credential for a major enterprise AI platform, although the platform itself was not identified.
The potential consequences of exposed credentials vary depending on the permissions attached to individual keys. A compromised API key can potentially allow unauthorised use of an account’s quota, generate unexpected charges or provide access to services and resources connected to the affected account.
The findings did not establish whether the exposed credentials had already been abused.
Zimmermann also said he had not confirmed at the time of publication whether all affected vendors had revoked the credentials that were reported to them.
Full Commit Histories Were Scanned
The research used two secret-scanning tools, TruffleHog and Kingfisher, to examine every repository included in the study.
Both tools attempted to verify discovered credentials directly against the services that issued them, allowing the researchers to count only credentials that were still working when checked.
Importantly, the scanners examined the complete commit history of repositories rather than only the latest version of the code.
This means a developer who accidentally uploaded a credential and later deleted it from the current code could still have the secret exposed through an earlier commit.
Of the 26,400 credentials identified, 12,242 were associated with commits dating from 2025, representing nearly half of the total. Some exposed credentials dated back to the late 2000s.
The total counted each credential only once, even if the same credential appeared in multiple repositories.
The scan reportedly ran for around one month, although the exact dates were not disclosed. As a result, it remains unclear precisely how recently each credential was tested.
Two Scanners Found Very Different Secrets
The research also highlighted differences between the two secret-detection tools.
TruffleHog identified 12,737 working credentials, while Kingfisher found 14,664. Only 1,001 credentials were detected by both tools.
TruffleHog identified almost all of the exposed Alibaba Cloud credentials.
Kingfisher, meanwhile, detected all 1,489 Zhipu BigModel keys because TruffleHog did not have a detector designed for that particular credential type.
The findings suggest that organisations relying on only one secret-scanning tool may fail to detect credentials associated with services that the tool does not support.
Developers and security teams therefore need to verify whether the scanning products they use include detectors for the cloud, AI and software services deployed within their environments.
Deleted Keys May Still Remain Dangerous
Removing credentials from visible source code does not automatically make them safe.
If a secret has ever been committed to a publicly accessible repository, it should generally be treated as compromised because copies may already have been downloaded, indexed or preserved in repository history.
Developers affected by such exposure should revoke the old credential through the relevant service provider and create a replacement.
For Alibaba Cloud AccessKeys, the response process includes generating a new key pair, migrating applications to the replacement credentials and disabling the exposed keys.
Google and YouTube API keys can similarly be rotated, while restrictions can be applied to limit which APIs and applications are authorised to use them.
OpenAI also advises users to rotate compromised API keys immediately and use spending controls to reduce the financial impact of unauthorised use.
Simply deleting a credential from the repository is therefore not sufficient protection if the key itself continues to remain active.
Gitee Exposure Rate Raises Security Questions
Gitee was selected by China’s Ministry of Industry and Information Technology in 2020 as the foundation for a national open-source code-hosting platform.
The latest research found 3.64 valid credentials for every 1,000 repositories scanned on Gitee.
Earlier research cited in the study found rates of 3.11 credentials per 1,000 repositories on GitLab and 2.39 on Bitbucket.
However, direct comparisons have limitations because the earlier scans relied only on TruffleHog, while the Gitee research used both TruffleHog and Kingfisher.
When only TruffleHog results were considered, Gitee’s rate fell to 1.76 valid credentials per 1,000 repositories.
This difference shows how strongly reported exposure levels can depend on the scanners and credential detectors used.
The findings underline a broader software security problem: cloud and AI credentials embedded in public code can remain active long after developers believe they have been removed.
For organisations increasingly dependent on cloud infrastructure and AI APIs, automated secret scanning, key rotation, repository monitoring and strict credential management are becoming essential safeguards against accidental exposure and unauthorised access.
About the author — Suvedita Nath is a science student with a growing interest in cybercrime and digital safety. She writes on online activity, cyber threats, and technology-driven risks. Her work focuses on clarity, accuracy, and public awareness.
