Truffle Security: Over 540,000 Valid Credentials Confirmed in Public GitHub Repositories

1. Overview

• Report Title: GitHub Repos Exposed 543,699 Credentials. Nobody Revoked Them.
• Publisher: Truffle Security
• Publication Date: 2026-09-29
• Source: Truffle Security
• Related Sources: BleepingComputer, GitHub secret scanning patterns
• Severity: High (The study quantifies gaps in credential rotation and revocation within a single corpus, highlighting the volume of valid credentials, a reported median estimated age of 784 days based on file timestamps, and gaps in default protection coverage.)

2. Executive Summary

Truffle Security examined a large snapshot of public GitHub repositories and analyzed 543,699 credentials that authenticated when tested in July 2026 and could be associated with usable file timestamps. Exposure density for protected patterns declined by 53% in a comparison of periods before and after Push Protection became enabled by default. Under the study's classification, however, 51.8% of the analyzed credentials fell outside default blocking coverage.

3. Scope and Methodology

• The analysis covered 224,553,295 repositories and 58,467,468,698 file entries in The Stack v3, whose crawl ended on August 7, 2025. The dataset contains default branch snapshots only and excludes commit history.

Evaluation Design

• File last-modified timestamps served as a proxy for exposure dates. Credential validity was tested on July 27–28, 2026. Credentials were deduplicated by value, using the earliest file timestamp across copies of each credential. Google API keys were counted as valid only if they authenticated to Gemini; their validity for other Google services was not tested. The entire Google API key family was therefore excluded from both the numerator and denominator of survival-rate calculations.

4. Key Findings

• For the 543,699 credentials with verified validity and usable timestamps, the study reports a median estimated interval of 784 days between the file timestamp and verification, a 90th percentile of 6.3 years, and a maximum of 16.1 years.
• Of the 543,699 analyzed credentials, 199,843 (36.8%) had file timestamps on or after February 29, 2024, when Push Protection became enabled by default. Separately, under the study's classification, 51.8% of the entire analysis set fell outside default blocking coverage.
• Comparing the 12-month periods on either side of March 2024, median monthly credential density, measured in credentials per million files, declined by 53% in the protected group and 7% in the unprotected group. This is an observational comparison of periods before and after deployment, not the percentage of individual pushes blocked.
• Among candidates identifiable as credentials from their formats and tested by provider, 1 of 101,886 npm tokens, 260 of 73,048 GitHub tokens, and 69,041 of 126,963 Google Cloud service account credentials authenticated successfully. These denominators include candidates regardless of their verification outcome and differ from the analysis set of 543,699 valid credentials.

5. Interpretation and Limitations

• The corpus contains default branch snapshots from a crawl that ended on August 7, 2025. It excludes commit history and deleted branches. File timestamps are proxies for exposure dates.
• The MongoDB detector reports a URI only after successfully connecting, so MongoDB was excluded from both survival-rate and exposure-density calculations. Private keys cannot be verified from their value alone and were excluded from survival rates. Failed verification can reflect deletion at the issuer as well as revocation.
• The study did not measure whether the credentials had been misused.
• The study's discussion of the 51.8% figure mentions private keys, while its methodology states that private keys cannot be verified from their value alone and excludes them from survival-rate calculations. Their treatment in the aggregate requires clarification against the underlying data.

6. Facts, Inference, and Hypothesis

Facts

• The scan covered 224,553,295 repositories and 58,467,468,698 file entries from The Stack v3 and detected 544,069 distinct valid credentials during verification on July 27–28, 2026. Of these, 543,699 could be mapped to corpus files with usable timestamps and formed the primary analysis set.
• For the 543,699 analyzed credentials, the study reports an estimated age based on file timestamps of 784 days at the median, 6.3 years at the 90th percentile, and 16.1 years at the maximum. These figures do not directly establish the initial exposure date or show that the credentials remained valid continuously throughout those periods.
• Of the 543,699 analyzed credentials, 199,843 (36.8%) had file timestamps on or after February 29, 2024. The 51.8% figure uses the entire analysis set as its denominator, not the subset of 199,843 credentials, and reflects the study's classification of credentials outside default Push Protection coverage.
• Comparing the 12-month periods on either side of March 2024, median monthly credential density per million files declined by 53% in the protected group and 7% in the unprotected group. The comparison used six protected credential families and six unprotected families, all already present in 2021, and excluded MongoDB.
• Of 101,886 npm token candidates, 1 was valid. Of 126,963 Google Cloud service account credential candidates, 69,041 were valid.

Inference

• Blocking pushes and revoking credentials after exposure are separate controls. Risk remains if credentials exposed in repository history, or credentials outside default protection coverage, are not rotated.
• Provider-specific survival rates can inform post-detection revocation practices, but failed verification cannot always be attributed to successful automated revocation. Comparisons of credential density before and after Push Protection deployment also cannot rule out concurrent factors, such as the adoption of short-lived credentials or workload identity.

Hypothesis

No additional hypotheses. Unconfirmed items are listed in Section 7.

7. Open Questions and Further Investigation

• What proportion of the 543,699 credentials were obtained or misused by third parties?
• Have the respective repository owners been notified, and has credential rotation been completed?
• How many exposed credentials remain valid when non-default branches, deleted commit history, and new exposures after August 7, 2025, are taken into account?

8. Implications for Defenders

Organizations need to track more than secret scanning alert counts. They should establish whether exposed credentials remain valid, identify their owners, and confirm that rotation and session revocation are complete. Blocking pushes to public repositories is important, but organizations also need to scan repository history and separately check formats that the study classified as outside default Push Protection coverage, including connection strings, private keys, and Google API or Gemini keys. When exposure is detected, credentials should be revoked before the exposed material is removed.

Deployment and Operational Guidance

• Revoke committed credentials immediately, then clean up repository history.
• Add scans for generic secret patterns and database connection strings, and move toward short-lived credentials and workload identity.

Required Evidence

• Correlate secret alerts, repositories and commits, credential owners, issuer-side authentication logs, rotation completion timestamps, and confirmation that the old credentials have been revoked.

9. Summary by Audience

• For SOCs: Connect source code exposure alerts with identity and cloud audit logs to track credential validity, usage history, and rotation completion.
• For Administrators: Scan public repository history comprehensively, identify patterns outside default protection coverage and long-lived credentials, and migrate to short-lived credentials.
• For Users: Avoid storing credentials directly in code or configuration files. If credentials are accidentally committed, rotate them immediately; deletion alone is insufficient.