500,000 Active Credentials Left Exposed on GitHub

1. Executive summary

Truffle Security scanned 224 million public GitHub repositories in August 2025 and found 1,103,438 exposed credentials; when the firm re-tested the set against the issuing providers at the end of July 2026, 543,699 were still active. The oldest is an AWS key committed in 2009 and untouched since, and the median exposure window across the set is 784 days. Nearly half of the live credentials, 199,843, were pushed after GitHub made push protection the default, which means the control that stops secrets at the door has no effect on the secrets already inside the repository history. For EMEA financial services the exposure is not the leak itself but the revocation gap: a live Google Cloud service account key or MongoDB connection string in a public repository is standing access to production data, and the provider-side pipeline that should have killed it does not exist. No CVE, no exploitation in the wild, and no named threat actor is attached to this item; the risk is credential reuse and standing access, not a vulnerability.

2. Regulatory framing

No specific DORA or NIS2 article is directly engaged by the incident-reporting obligations (DORA Art. 17, 18, 19; NIS2 Art. 23) on the facts available: the source describes a research finding, not an incident at a named entity, and no client is identified as affected.

3. Technical analysis & attack chain

This is a research finding, not an intrusion. There is no exploited component and no attacker in the source material. The chain below is the exposure-to-access path a defender should reason about, and every step is drawn from the Truffle Security findings as reported.

1. A developer commits a credential to a public GitHub repository. The credential is a live secret for a connected service: Google Cloud service account, MongoDB connection string, Google API key, or AWS key.
2. The credential remains in the repository history. Push protection blocks the commit at the door if it is enabled; it does not remove secrets already committed, and it does not revoke them.
3. GitHub's secret-scanning program detects the exposed token and forwards it to the issuing provider. The program does not require the provider to revoke the secret.
4. The provider does not revoke. Truffle's stated reason is that providers may not have a pipeline that kills leaked tokens. The credential stays valid.
5. Anyone who reads the public repository can use the credential against the connected service. The source does not describe any actor doing so, and no misuse is reported.

The scale and age distribution are the operationally relevant facts. Of the 1,103,438 credentials found in the August 2025 scan, 543,699 were still active at the end of July 2026. The median exposure window is 784 days. 2,636 live credentials come from files last modified before 2015, and a quarter of everything found is older than four years. The oldest is an AWS key committed in 2009 and untouched since.

The push-protection timeline is the part that matters for control design. 245,959 credentials predate free alerts. 97,897 arrived while scanning was free and push protection was one setting away. 199,843 landed after the block became the default and were still answering to their providers more than two years later. Truffle's own framing is that push protection stops secrets at the door and has nothing to say about the 543,699 already inside, and that alerts cover history only where an owner enabled them, read them, and then rotated the key.

The exposed set is dominated by 69,041 Google Cloud service account credentials, 51,067 MongoDB connection strings, and 33,343 live Google API keys. Those three classes are the ones to prioritise in any inventory sweep: service account credentials and database connection strings carry standing access to systems and data, not just to an API surface.

Confidence caveats. The entire finding is single-sourced to Truffle Security; the underlying scan methodology, the provider re-test procedure, and the per-class counts have not been independently corroborated. The 543,699 figure is a point-in-time re-test at the end of July 2026, not a live count. The claim that providers lack a revocation pipeline is Truffle's explanation for the active count, not a verified statement about any named provider's internal process. Treat the numbers as directionally reliable and the causal explanation as unconfirmed.

A separate, related finding from Hush Security (September 2026) analysed around 82,000 MCP configuration files on GitHub and found that 12% of credential slots contained a hardcoded credential literal, potentially exposing credentials for connected services used by AI coding tools. That is a different dataset and a different credential class from the Truffle scan; do not merge the two counts. It is also single-sourced.

4. Mitigation & containment

P1 within 24h

• Run a secret scan across all repositories your organisation owns or has forked, including full history, not just the default branch. GitHub secret scanning covers history only where an owner has enabled it; confirm it is enabled for every organisation and repository, then read the alerts.
• For every hit, revoke the credential at the provider first, then rotate. Deleting the commit or force-pushing does not revoke anything, and the credential remains valid until the provider kills it.
• Prioritise by credential class: Google Cloud service accounts, MongoDB connection strings, and Google API keys first, then AWS keys. These carry standing access to systems and data.
• Check for credentials committed before 2015 and any file last modified more than four years ago. The source shows 2,636 live credentials in that age band; old secrets are the least likely to have been rotated and the most likely to still be valid.

P2 within 72h

• Turn on push protection as a default at the organisation level, not per repository. The source shows 199,843 credentials arrived after the default was enabled, so confirm the setting is actually applied to the repositories your developers push to.
• Inventory third-party service credentials held in code and map each to the provider contract. Where the contract does not commit the provider to act on a leaked-credential notification within a defined window, raise it as a DORA Art. 30 contractual gap.
• Replace long-lived service account keys with short-lived, workload-identity-based credentials where the provider supports it. A credential that expires cannot sit live for 784 days.

P3 within 7 days

• Add a pre-commit hook and a CI-stage secret scan so a credential is caught before it reaches the remote, and treat a detected secret as a revocation event, not a cleanup task.
• Review MCP configuration files and any AI coding tool configuration committed to repositories for hardcoded credential literals, on the Hush Security finding that 12% of credential slots in the sampled files contained one.
• Add leaked-credential revocation to the incident process so that a secret-scanning alert has an owner and a closure criterion (revoked and rotated), not just a status of acknowledged.

5. Indicators of compromise

No indicators of compromise available in the source material. The source describes aggregate counts and credential classes, not atomic indicators. No hashes, domains, IP addresses, file paths, or registry keys are given, and none should be inferred.

Behavioural indicators

6. Detection

Insufficient indicators to author detection rules. The source material contains no distinctive strings, command-line flags, mutex names, scheduled-task or service names, file names, registry keys, or hard-coded values belonging to a threat artefact. The only artefacts are aggregate counts and credential class names, which are reporting about the exposure, not indicators of it. A YARA or Sigma rule built on those would match the reporting, not the exposure.

Detection for this item belongs in repository and provider telemetry, not in endpoint or network rules: enable GitHub secret scanning and push protection at the organisation level, alert on secret-scanning findings, and alert on provider audit-log use of a credential that appears in a public repository.

7. Sources

• Truffle Security, via SecurityWeek, "500,000 Active Credentials Left Exposed on GitHub", https://www.securityweek.com/500000-active-credentials-left-exposed-on-github/, 2026-10-01
• Hush Security, "The State of MCP Configuration: The Identity Security Gaps report", via Help Net Security, "Hardcoded MCP credentials found in public GitHub files", https://www.helpnetsecurity.com/2026/09/18/hush-security-mcp-credential-exposure-report/, 2026-09-18
• Cybersecurity Dive, "CISA details security lapses that led to GitHub leak of passwords, cloud access keys", https://www.cybersecuritydive.com/news/cisa-github-passwords-leak-contractor-report/824953/, date not stated in the supplied extract

8. Adverse Trace position

Adverse Trace assesses this as a high-impact exposure finding with no exploitation reported and no attribution: there is no CVE, no CISA KEV entry, and no named actor in the source material, so the severity sits with the 543,699 live credentials and the 784-day median exposure window, not with an active campaign. The client impact is concentrated in firms that hold third-party cloud and database credentials in code, because those credentials grant standing access to production systems and the provider-side revocation path is not guaranteed. We will track whether the Truffle figures are independently corroborated, whether any named provider changes its revocation obligations in response, and whether the Hush MCP configuration finding expands into a second credential class worth a separate advisory. The single action we would put in front of a client this week is a full-history secret scan with revocation at the provider, because the source is explicit that prevention controls do not touch the credentials already inside.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.