Full Report
More than 543,000 credentials exposed in public GitHub repositories were still valid in July despite the platform's security measures to prevent accidental leaks of sensitive data. [...]
Analysis Summary
# Incident Report: Large-Scale Exposure of Valid Credentials on GitHub
## Executive Summary
A large-scale security analysis by Truffle Security revealed that over 543,000 unique, valid credentials remain exposed in public GitHub repositories. Despite the implementation of GitHub's "Push Protection" feature, hundreds of thousands of secrets persist due to historic leaks, unblocked credential types, and a lack of proactive revocation by users. The findings highlight a systemic failure in secret management, with some working credentials remaining active for over a decade.
## Incident Details
- **Discovery Date:** Analysis concluded August 7, 2025 (Results published September 2026)
- **Incident Date:** Ongoing; oldest valid credential dates back to 2009
- **Affected Organization:** Multiple (spanning millions of public repositories)
- **Sector:** Global Technology, Software Development, Cloud Services
- **Geography:** Global
## Timeline of Events
### Initial Access
- **Date/Time:** 2009 – Present
- **Vector:** Accidental exposure via public code commits.
- **Details:** Developers inadvertently committed sensitive secrets (API keys, database strings, tokens) into public repositories or forks.
### Lateral Movement
- **Details:** While the report focuses on exposure, the identified credentials (e.g., Google Cloud Service Accounts) provide the primary mechanism for attackers to move from public code repositories into private cloud environments and databases.
### Data Exfiltration/Impact
- **Details:** 543,699 unique valid credentials identified across 1.1 million files. Exposure includes npm tokens, Google API keys, and database connection strings.
### Detection & Response
- **Discovery:** Truffle Security scanned a dataset of 224 million repositories and 58 billion files used for LLM training.
- **Response Actions Taken:** GitHub implemented "Push Protection" by default in early 2024 to block new leaks, though it does not address existing historical exposures.
## Attack Methodology
- **Initial Access:** Plaintext credentials stored in public version control systems (GitHub).
- **Persistence:** Long-lived tokens; 10% of working credentials have been valid for over 6.3 years.
- **Privilege Escalation:** Accessing high-privileged service accounts (e.g., Google Cloud).
- **Defense Evasion:** Use of credential types not currently covered by GitHub’s default Push Protection patterns (approx. 51.8% of leaked secrets).
- **Credential Access:** Scraping public repositories and forks.
- **Discovery:** Automated scanning of public GitHub datasets.
- **Lateral Movement:** Using leaked database connection strings or cloud service account keys to access backend infrastructure.
- **Collection:** Harvesting secrets from commit history and forked repositories.
- **Impact:** Potential for unauthorized data access, resource hijacking, and full corporate account takeover.
## Impact Assessment
- **Financial:** High potential risk due to unauthorized cloud resource usage and potential regulatory fines for data breaches.
- **Data Breach:** Exposure of over 543,000 valid entry points into various corporate and personal environments.
- **Operational:** Risk of service disruption if attackers use credentials to modify or delete infrastructure.
- **Reputational:** High risk for organizations identified in the leak; highlights poor DevSecOps practices.
## Indicators of Compromise
- **Network indicators:** N/A (General exposure report).
- **File indicators:** Presence of high-entropy strings, `id_rsa` files, `.env` files, or hardcoded strings matching patterns for `AIza...` (Google) or database URIs in public `.git` history.
- **Behavioral indicators:** Unusual API calls or logins originating from unexpected IP addresses using long-dormant keys.
## Response Actions
- **Containment:** GitHub enabled "Push Protection" by default for all public repositories in February 2024.
- **Eradication:** Recommendation for users to rotate all exposed secrets immediately.
- **Recovery:** Cleaning repository history using tools like BFG Repo-Cleaner or `git-filter-repo` to remove sensitive strings from all branches and tags.
## Lessons Learned
- **Key takeaways:** Automated blocking (Push Protection) is effective for new leaks (53% reduction in covered categories) but does not solve the "backlog" of old secrets.
- **What could have been done better:** Organizations frequently fail to revoke secrets even after deleting the offending code; deleting a file does not remove it from Git history or forks.
## Recommendations
- **Rotate Secrets Immediately:** Treat any secret ever committed to a public repo as compromised, even if the repo is now private or the code is deleted.
- **Expand Scanning:** Use specialized secret scanning tools that look for a wider variety of patterns than default platform protections (e.g., database connection strings).
- **Implement Short-Lived Credentials:** Move away from long-lived API keys in favor of short-lived tokens or OIDC-based authentication.
- **Automated Revocation:** Service providers should implement automated revocation when their tokens are detected in public scans (similar to the high success rate observed with npm tokens).