Public code repositories remain one of the most prolific conduits for unintentional corporate secret leakage. In late October 2026, independent cybersecurity researcher Ben Zimmermann published the results of an exhaustive security scan evaluating Gitee—China's largest open-source and collaborative code hosting platform. The scan uncovered that over 26,400 live, verified credentials had been inadvertently left exposed across public git repositories.
Critically, unlike automated research scans that merely flag strings matching known API token regular expressions, this audit actively authenticated each discovered secret against the issuing service's live API endpoint. Every one of the 26,400 cataloged secrets was confirmed to be functional and active at the time of discovery.
Breakdown of Exposed Credentials by Infrastructure Provider
The audit analyzed the full commit histories of approximately 7.25 million public Gitee repositories using automated scanning engines (TruffleHog and Kingfisher). The findings revealed disproportionate exposure across major cloud infrastructure platforms and generative AI providers:
| Target Service / Provider | Verified Live Keys Found | Potential Security Impact |
|---|---|---|
| Alibaba Cloud (Aliyun) | 9,473 AccessKey Pairs | Full cloud infrastructure takeover, ECS instance spinning, data bucket theft. |
| OpenAI & Enterprise AI APIs | 3,120 API Keys | LLMjacking, unauthorized model inference, fine-tuning dataset exfiltration. |
| DeepSeek & Zhipu BigModel | 2,845 API Keys | Model quota depletion, enterprise data poisoning, prompt extraction. |
| Tencent Cloud & Baidu Cloud | 2,410 SecretId/SecretKey Pairs | Compute resource hijacking, internal corporate database access. |
| Google Cloud & AWS | 1,850 Access Keys / JSON Keys | S3 bucket exfiltration, IAM role escalation, Kubernetes takeover. |
The Git History Trap: Why Deleting Files Does Not Fix Leaks
The research highlighted a fundamental misunderstanding among developers regarding version control architecture: nearly half (12,242) of the valid credentials originated from historical git commits rather than the current, visible HEAD state of the repository.
Developers frequently commit an API key in a configuration file (such as config.json or .env) during early development, subsequently realize their error, delete the file in a follow-up commit, and push the changes. However, git preserves the entire immutable chronological commit tree. Any threat actor cloning the repository can traverse historical diffs to recover the plaintext key in milliseconds.
Organizational Hardening & Prevention Playbook
Security engineering teams must enforce rigorous secrets management workflows to prevent cloud credentials from reaching external repositories:
- Enforce Pre-Commit Scanning Hooks: Mandate tools like
gitleaksorpre-commitin developer environments to block commits containing sensitive strings before they leave local workstations:# Install and enable pre-commit secret detection pip install pre-commit pre-commit install --hook-type pre-commit - Purge Historical Git Trees via BFG: If a credential is accidentally committed, simply deleting it is insufficient. Use the BFG Repo-Cleaner to rewrite history before force-pushing:
# Completely scrub a file or secret from all historical commits bfg --delete-files .env my-repo.git git reflog expire --expire=now --all && git gc --prune=now --aggressive - Enforce Cloud IAM Key Expiration: Transition away from long-lived static AccessKeys. Mandate OpenID Connect (OIDC) identity federation between CI/CD pipelines and cloud providers, eliminating hardcoded secrets entirely.
