Secrets in CI: How Credential Leaks Actually Happen (and the Push Protection Fix)

Posted Aug 27, 2026

A golden key slips through a crack in a CI pipeline stage while a green shield with scan lines blocks further exposure

By ML Kenya

5 min read

Secrets in CI: How Credential Leaks Actually Happen (and the Push Protection Fix)

The 39 Million Secret Problem

GitHub’s secret scanning service found more than 39 million secrets leaked across the platform in 2024 alone — and push protection still blocks several secrets every minute (GitHub Blog, SecurityWeek, BleepingComputer). These are API keys, personal access tokens, cloud credentials, database passwords, and signing keys — the exact credentials that let CI pipelines build, deploy, and move money.

The key concept Credential leaks are not exotic nation-state operations. They are committed files, unrotated tokens, and provider compromises — and for fintechs, a leaked CI secret is a direct path to production systems and customer data.

Anatomy: Three Ways Secrets Escape CI

1. The CI Provider Is a Vault — and Vaults Get Robbed

CircleCI is the canonical case. On December 16, 2022, malware landed on a CircleCI engineer’s laptop — and their antivirus did not detect it. The malware executed session-cookie theft, letting the attacker impersonate the employee despite 2FA, then escalate into production systems. Because the employee’s role included generating production access tokens, the attacker exfiltrated customer environment variables, tokens, and keys on December 22, pulling encryption keys out of a running process to decrypt data at rest (CircleCI incident report, Malwarebytes).

CircleCI’s response is the lesson: on December 31 it proactively rotated all GitHub OAuth tokens on behalf of every customer, and on January 4, 2023 it told the world to rotate any secrets stored in CircleCI (security alert). A CI provider is a secrets concentration point — when it is compromised, every project’s secrets are suspect. Rotation must be broad, not surgical.

2. The Over-Scoped Token in a Public Repo

On September 29, 2023, researchers at RedHunt Labs found a GitHub token in a public repository belonging to a Mercedes-Benz employee. The token gave “unrestricted” and “unmonitored” access to the company’s entire internal GitHub Enterprise Server — database connection strings, cloud access keys, blueprints, SSO passwords, and API keys (BleepingComputer, RedHunt Labs). The token sat in the open for months; the company was informed on January 22, 2024 and revoked it two days later.

Toyota’s 2022 disclosure shows the same failure at larger scale: an exposed GitHub access key left customer information publicly accessible for roughly five years (BleepingComputer). One over-scoped token plus one public repo equals the whole organization exposed — and as the Mercedes report notes, you only generate evidence of abuse if audit logs are enabled.

3. Even the Defenders Leak

In May 2026, GitGuardian researcher Guillaume Valadon found a public GitHub repository named Private-CISA — created November 13, 2025 — stuffed with internal CISA/DHS credentials: AWS GovCloud keys, GitHub personal access tokens, plaintext passwords, JFrog Artifactory tokens, Azure registry keys, Kubernetes manifests, Terraform code, and Entra ID SAML certificates. It even contained an explicit how-to guide for disabling GitHub’s secret scanning (Krebs on Security, Dark Reading, The Register). The repo was taken down roughly 26 hours after discovery, following escalation through journalist Brian Krebs. The agency tasked with defending US networks ran the same unsafe playbook as everyone else — the problem is process, not people.

4. The Firsthand Case: This Blog’s Own Push

This repository hit the wall GitHub built. A Supabase personal access token sat in an old commit in our history; when a later push went up, GitHub push protection rejected it with a GH013 rule violation, pointing at the exact commit and file (GitHub docs). The fix was an interactive rebase to redact the token, an amended commit, and a force-push. The uncomfortable truth: secret scanning catches tokens in history, not just in new commits — a secret committed once never dies until it is scrubbed and rotated.

How We Can Do Better

Control	What it stops	Case that proves it
Secret scanning + push protection on	tokens entering the repo at all	CISA repo (scanning disabled on purpose)
Rotate broadly after any provider breach	stolen secrets staying valid	CircleCI (all OAuth tokens rotated)
Short-lived credentials (OIDC, scoped tokens)	a leaked token being worth anything	Mercedes (unrestricted token, 4 months)
Inject secrets at runtime from a vault; mask logs	secrets in code and build output	CircleCI (env vars exfiltrated)
Pin actions to commit SHAs	supply-chain tampering in CI	CI/CD as a Security Control
Enable audit logs	silently reusing a leaked token	Mercedes (no evidence without logs)
Scan git history (gitleaks/trufflehog)	old commits re-exposing secrets	our own GH013 push block

For fintechs running payments through CI, treat the pipeline as critical infrastructure: a leaked CI secret is a fraud risk, not just a security risk — the same blast radius as the NCBA contractor incident but reachable remotely.

Conclusion

The 39 million figure is not a headline — it is the baseline. CI secrets leak through provider compromise (CircleCI), over-scoped tokens in public repos (Mercedes-Benz, Toyota), and plain process failure (CISA). The controls are cheap and mostly free: turn on secret scanning and push protection, rotate broadly after any breach, prefer short-lived credentials, and treat old git history as contaminated until proven otherwise.

References

Cybersecurity, ML Ops

This post is licensed under CC BY 4.0 by the author.