A new security finding highlights a familiar but still costly problem for development teams: secrets embedded in public code repositories. According to independent researcher Ben Zimmermann, 26,400 credentials exposed in public repositories on Gitee, a Chinese code-hosting platform, were still valid when tested. The result points to an ongoing risk for companies using cloud, AI and developer platforms, especially where code is shared publicly or copied across teams without proper secret management.

What happened

Zimmermann said he scanned 7.25 million public Gitee repositories and identified exposed credentials left in code by developers. He reported the findings on October 28. According to the report cited by The Hacker News, 26,400 of those credentials were still valid at the time of testing, meaning they could potentially be used by anyone who found them.

The exposed secrets were described as mainly relating to cloud and AI services. That matters because these credentials can provide access to paid APIs, cloud infrastructure, storage, development environments or automation workflows, depending on the permissions attached to each key.

The available reporting indicates a researcher identified and tested the credentials. It does not, by itself, prove criminal misuse in each case. However, valid credentials in public code are generally treated as a serious security exposure because they can be copied quickly and used without exploiting any software vulnerability.

Why it matters for European businesses

For European companies, the issue is not limited to one code-hosting platform or one geography. The underlying problem is broader: developers still commit API keys, tokens and passwords into public repositories, examples, prototypes and internal tools that later become visible outside the business.

This can create several business risks:

• Unauthorised access to cloud resources: Exposed keys may allow attackers to access storage, compute services, databases or admin tools.
• Unexpected costs: Stolen AI or cloud API credentials can be abused to generate usage charges.
• Data exposure: If a credential grants access to production systems, logs or storage buckets, customer or business data may be at risk.
• Operational disruption: Attackers can alter configurations, delete resources or use compromised accounts as a foothold for further attacks.
• Compliance consequences: If exposed credentials contribute to a personal data breach or security incident, GDPR and sector-specific obligations may become relevant.

The finding is also relevant because AI adoption is increasing across SMEs and digital teams. Many businesses now use third-party AI APIs for customer support, content workflows, coding assistants or internal automation. These services often rely on simple bearer tokens or API keys, which are easy to leak if developers hard-code them into applications or publish test code online.

Who may be affected

The immediate risk applies to any organisation that publishes code publicly or works with contractors, agencies or distributed development teams across multiple repositories and platforms.

• SMEs and startups: Smaller teams often move quickly and may have weaker controls around secret rotation and repository scanning.
• E-commerce businesses: Exposed keys may affect cloud hosting, analytics, integrations, payment-related systems or customer data flows.
• IT and engineering teams: Developers, DevOps and platform teams are directly responsible for repository hygiene and access control.
• Marketing and automation teams: No-code and API-based tools often rely on tokens stored in scripts, plugins or integration files that may be mishandled.
• Agencies and software suppliers: Service providers managing client code or infrastructure may expose not only their own keys but also customer environments.

Even businesses that do not use Gitee specifically should pay attention. Similar problems have repeatedly appeared on mainstream code-hosting and collaboration platforms, making this a cross-platform software security issue rather than a localised one.

What companies should consider

• Scan repositories for secrets: Check public and private repositories, including old projects, sample code, documentation and archived branches.
• Rotate exposed credentials immediately: Deleting a key from visible code is not enough if it has already been committed and copied. Revoke and replace it.
• Use a secrets management approach: Store API keys and tokens in dedicated secret stores, environment variables or managed vaults rather than in source code.
• Limit permissions: Apply least-privilege access so a leaked credential cannot expose more systems than necessary.
• Enable monitoring and alerts: Watch for unusual usage, especially on AI APIs, cloud billing, storage access and developer accounts.
• Review third-party development practices: Agencies, freelancers and software vendors should follow the same secret-handling standards as internal teams.
• Include AI tools in credential policies: AI API keys should be governed like other production credentials, with ownership, rotation and usage controls.

For regulated or security-sensitive businesses, this is also a reminder to link development practices with broader governance. Repository scanning, credential rotation and access reviews are practical controls that can reduce both cyber risk and the fallout from a future audit or incident response process.

While the reported exposure concerns Gitee repositories, the practical lesson for European businesses is wider: any public code platform can become a channel for credential leaks. As companies expand their use of cloud and AI services, basic secret management remains one of the most important and often overlooked cybersecurity controls.