Leaked secret breaches: where secrets were left and how they were found

Most leaked secret breaches do not start with a clever attack: a working key sits somewhere it should never be, often for months or years, until a researcher, a journalist or an attacker finds it first. NHI Mgmt Group's The State of NHI & AI Agent Breach Report 2026 (October 2026) found that 48 of the 200+ breaches in its database began with a secret left in code, logs, images or tickets. This guide maps where those secrets were left, who found them and how long they stayed valid, then turns the pattern into controls for each hiding place and a response sequence that does not stop at deleting the file. It is for AppSec, platform and identity teams who run secret scanning and own the credentials it finds. The OWASP NHI Top 10 NHI2 Secret Leakage Guide covers the risk itself; this page is the breach evidence and what to do about it.

Key takeaways

• Leaked secrets are the second most common route in. The report counts 48 breaches (21%), close behind supply chain, and names secret or password as the most exploited identity type (84 breaches).
• The hiding places are predictable. Public and private repositories, configuration files on dev servers, compiled files in container images, CI artifacts and logs, signed URLs and leaked source code account for every case on this page.
• Exposure windows are long, response windows short. Toyota's key was public for about five years, Microsoft's SAS token for about three, PyPI's admin token for 15 months, yet PyPI revoked within 17 minutes of a report.
• Outsiders find most leaks. Researchers found the Microsoft, PyPI, Home Depot and CISA exposures. A working disclosure channel is a detection control.
• Deleting is not revoking. The Internet Archive's second breach used Zendesk tokens that were not rotated after the first, and CISA's AWS keys stayed valid about 48 hours after the repository came down.

What the report data shows

Figures in this table are from NHI Mgmt Group, The State of NHI & AI Agent Breach Report 2026 (October 2026), covering November 2017 to October 2026. One breach can carry several routes and identity types.

The report places this route under two lifecycle stages, Secretless Credentials and Continuous Discovery & Inventory, and lists the controls as: scan code, CI logs, images and tickets for secrets; vault what you find; rotate on exposure; replace long-lived keys with short-lived, scoped credentials. The 56% figure explains why one leak rarely stays one: a leaked key is used to find the next credential.

Where the secrets were left

Four patterns across the cases

1. The secret outlived its purpose

Toyota's key, Microsoft's SAS token and PyPI's PAT were all long-lived and broad. None had a forced expiry the organisation relied on. A 2051 expiry is no expiry. Short lifetimes would have closed most of these windows without anyone finding the leak.

2. Scanning looked at source, not at what ships

PyPI's token was never committed: it was in a compiled file baked into an image because .dockerignore did not exclude __pycache__. ArtiPACKED tokens were in uploaded artifacts and log files. Scanning only commits misses images, packages, artifacts and logs. See the Secrets in Container Images and Build Artefacts Guide and How to find secrets in CI logs and build artefacts.

3. Private was treated as safe

Uber's key was in a private repository, reached through reused passwords without MFA. The Internet Archive's Zendesk tokens were inside source code that was itself stolen. A secret in a private store is one credential compromise away from public.

4. Response stopped at removal

Removing the file or making the repository private does not invalidate the secret. CISA's keys stayed valid about 48 hours after takedown. The Internet Archive was breached twice in a month. The same gap appears in the Zeabur Second Breach 2026, where admin tokens missed by the first rotation exposed about 3.2 million environment variable records.

Controls by hiding place

• Push protection: GitHub documents that push protection covers command line pushes, web UI commits, file uploads and REST API requests, and that by default anyone with write access can bypass it with a reason. Use delegated bypass so a reviewer approves, and restrict who can turn it off, since turning it off is how the CISA contractor's repository leaked. See the Push Protection Guide.
• Personal tokens for machines: PyPI's admin used a personal PAT to work around rate limits. Use GitHub Apps or fine-grained, repository-scoped tokens with expiry for automation.
• Separate source access from production: Home Depot's token reached cloud and pipelines as well as code. A source control token should not open production.
• Suppliers: Toyota's and CISA's leaks came from a subcontractor and a contractor. Put secret handling, push protection and exposure reporting in contracts.

Response: the sequence that works

1. Revoke first: invalidate the secret at the issuer within minutes. PyPI's 17-minute revocation is the benchmark; pre-agree the authority to do it.
2. Find everything that came with it: if source code or a repository was exposed, list every secret in it and rotate those too, starting with the most powerful. This is the Internet Archive lesson.
3. Review the whole exposure window: pull issuer and cloud logs from first exposure to revocation. PyPI could only review about 90 days of GitHub logs against a 15-month window, so retain source control audit logs longer than the platform default.
4. Remove the copy: delete the file, rewrite history where needed, delete artifacts and image tags, and request cache purges.
5. Prove the old secret fails: test it. Zeabur's earlier report wrongly stated all admin keys had been rotated.
6. Fix the cause: replace the secret with a short-lived or federated credential so the same leak cannot recur.

The full runbook is the Leaked Credential Response Playbook; for triage of scanner alerts see Developer Secret Scanning Triage.

Decision guidance

• Replace or rotate: if the platform supports workload identity federation or OIDC (cloud providers, registries, Vault), replace the static secret. Rotate on a schedule only where no federated option exists.
• Small teams: start with platform-native scanning and push protection on all repositories, a single vault and a public disclosure route. That covers the Toyota, Home Depot and CISA patterns.
• Large estates: add image and artifact scanning in the build, validity checks on findings, an owner for every secret, and automated revocation for high-confidence finds of cloud keys.
• Disclosure: publish a security.txt and staff it. Home Depot had no disclosure programme and the researcher's emails went unanswered. See the Bug Bounty and Vulnerability Disclosure Guide.

Implementation plan

1. Days 1 to 30: scan code, CI logs, container images, tickets and chat for secrets, then revoke and rotate anything live, as the report's 30-day plan sets out. Enable push protection on a pilot group of repositories, review bypass reasons for a week, then roll it out organisation-wide.
2. Days 30 to 60: add image and artifact scanning to build pipelines; set persist-credentials: false by default; publish security.txt.
3. Days 60 to 90: replace the long-lived cloud and source control credentials found with federated, short-lived ones; set maximum lifetimes; extend audit log retention.
4. Rollback: if enforcing push protection blocks releases, switch the affected repository to delegated bypass rather than disabling protection.

Detection and measurement

• Use of a known-leaked secret: alert on any authentication with a credential that has a scanner finding against it.
• Bulk repository access: mass clones or API listing by one token, the pattern behind the New York Times theft of about 270GB.
• Honeytokens: plant canary keys in repositories and images to detect anyone harvesting them. See the Honeytokens and Canary Credentials Guide.

Metrics:

• Median time from detection to revocation for valid secrets.
• Number of valid secrets open longer than seven days.
• Push protection bypasses per month, and the share reviewed.
• Percentage of images and artifacts scanned before publication.
• Percentage of cloud access from CI using federation instead of static keys.
• Audit log retention for source control, in days.

For measuring sprawl over time see the Secret Sprawl Measurement Guide.

Framework mapping

In CIS Controls v8.1 this sits in Control 3 (Data Protection) and Control 16 (Application Software Security); in ISO/IEC 27001:2022 Annex A, 5.17 (authentication information) and 8.4 (access to source code).

Common failure patterns

• Dismissing scanner findings: Microsoft's own scanning flagged the SAS URL and it was marked a false positive.
• Letting users switch off guardrails: the CISA contractor disabled push protection.
• Scanning only commits: PyPI's token was in a compiled file inside an image.
• Rotating the leaked key but not its neighbours: Internet Archive and Zeabur were breached again through credentials left valid.
• No owner, no route in: Home Depot's report went unanswered for weeks.

Practitioner checklist

• Enforce push protection on every repository with delegated bypass, and restrict who can disable it.
• Scan full history, container images, packages, CI artifacts, logs, tickets and chat.
• Monitor public code for your domains, key prefixes and supplier repositories.
• Set persist-credentials: false and upload only named build outputs.
• Give every secret an owner, a scope and a maximum lifetime.
• Replace static cloud and source control credentials in automation with federated, short-lived ones.
• Revoke within minutes, rotate everything exposed alongside, and test that old secrets fail.
• Retain source control and cloud audit logs long enough to cover realistic exposure windows.
• Publish and staff a disclosure route, and write secret handling into supplier contracts.

Standards and references

• NHI Mgmt Group: The State of NHI & AI Agent Breach Report 2026 (October 2026)
• GitHub Docs: About push protection
• GitHub Docs: Secure use reference for GitHub Actions
• MITRE ATT&CK: T1552 Unsecured Credentials
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• OWASP: Non-Human Identities Top 10

Related NHI Mgmt Group resources: Git Secret Scanning Guide · Environment Variables and .env Files · Azure SAS Tokens Security Guide · Non-Human Identity and Secrets Statistics Guide