543,699 Active Credentials Still Exposed on GitHub: The…

On July 27–28, 2026, Truffle Security verified in real time that 543,699 unique credentials remain active, found across 224,553,295 public GitHub repositories. The median exposure time is 784 days. Roughly 200,000 of these credentials were committed after GitHub enabled push protection by default on February 29, 2024. The data does not signal a detection failure, but a systemic revocation failure by cloud service providers.

{"main_topic":"cybersecurity","topics":["cybersec","vulnerabilita","cloud","api","developer"]}

Key Takeaways

543,699 unique active credentials as of July 2026 across 224 million public GitHub repositories, with a median exposure of 784 days
51.8% of active credentials belong to types not covered by GitHub's default push protection, including MongoDB connection strings and Google API keys
199,843 credentials (36.8%) were committed after February 2024, when GitHub enabled preventive blocking by default
The oldest active credential is an AWS key committed in November 2009, confirmed active after 16 years

The Research: Methodology and Sample Findings

Truffle Security analyzed The Stack v3 dataset, assembled for training large language models, with a crawl completed on August 7, 2025. The sample comprises 224,553,295 public repositories and 58,467,468,698 files. Candidate credentials were tested directly against issuing providers on July 27–28, 2026: 543,699 responded positively to authentication, confirming active status.

The figure of 1,103,438 total exposures includes duplicates across forks and different files, but unique active credentials total 543,699. The temporal median of exposure is calculated from the file's last modification timestamp to the verification date: 784 days, over two years. 25% of credentials are older than 4 years; 2,636 originate from files modified before 2015.

The density of active credentials in the dataset has grown over time: from 3.72 per million files in 2014 to 11.62 per million in 2025, according to Truffle Security's calculations on files from the same period. The largest category is Google Cloud service account credentials, with 69,041 active credentials.

Push Protection: Works Where It Applies, But Covers Less Than Half the Problem

GitHub enabled push protection by default on February 29, 2024, blocking commits of specific credential patterns. The mechanism recognizes over 200 secret types from more than 180 providers. According to data from BleepingComputer and Truffle Security, the exposure rate in protected categories dropped 53% after default activation.

However, 51.8% of active credentials found in July 2026 belong to types excluded from blocking. These include 51,067 MongoDB connection strings, 33,343 Google API keys and private keys. Google API keys are explicitly marked as "not push protected" in GitHub documentation by provider design.

Truffle Security stated the distinction unequivocally: "The block does work where it applies, roughly halving the rate at which the credentials it recognises reach public code, but 51.8 percent of what is still live is a shape it does not recognise." Push protection, according to the same source, "is a good control and stops secrets at the door. It has nothing to say about the 543,699 already inside, and it was never meant to."

The Forwarding Mechanism and the Revocation Void

GitHub operates the secret scanning partner program, which forwards exposed credentials to relevant providers. The mechanism is passive: the platform notifies, but does not enforce revocation. The provider may not act, may act partially, or may lack automated deactivation pipelines.

AWS represents a partial exception in this landscape. According to technical context from Palo Alto Networks' Unit 42, AWS responds to exposed credentials with the AWSCompromisedKeyQuarantine policy, which restricts permissions associated with the identified compromised key. The measure does not constitute automatic revocation: the key remains technically active, albeit with reduced operational capabilities.

The case of the 2009 AWS key — identified in a Rails configuration file for S3, confirmed active in the July 2026 test — illustrates the duration of the gap. No quarantine mechanism or notification deactivated the credential in 16 years, short of a manual revocation after Truffle Security's test.

"A leaked key that has been revoked is trivia. A leaked key that still authenticates is access." — Truffle Security

Why It Matters

The dossier does not specify how many of the 543,699 credentials were actually exploited by threat actors: Truffle Security did not analyze anomalous access nor track abuse. The report does not indicate the distribution between organizations and individual users, nor provide geographic or sectoral details. It is not documented whether providers initiated mass revocations after the data publication.

The brief does not list specific remedial measures by individual affected providers. No reason emerges for why categories such as Google API keys are not included in push protection, other than provider design choice. The dossier does not quantify the direct economic impact of the exposures.

The relevant figure for governance is persistence: 199,843 credentials committed after default push protection activation demonstrate that preventive controls do not eliminate the historical attack surface. The growth in exposure density over time, from 3.72 to 11.62 per million files, indicates that adoption of scanning tools has not reversed the structural trend.

Frequently Asked Questions

Has GitHub's push protection failed?: No, according to the report data it reduced the exposure rate in covered categories by 53%. The problem is that 51.8% of active credentials belong to categories excluded by design, and that pre-existing credentials were not revoked.
Why are credentials from 2009 still active?: The dossier documents that the AWS key was confirmed active in the July 2026 test, without indicating whether AWS or the owner acted subsequently. No mandatory revocation automations emerge for the prior period.
Are providers required to revoke?: According to the Truffle Security report and Unit 42 context, GitHub's forwarding mechanism is notification, not enforcement. Revocation is not mandatory and depends on each provider's internal policies.

The case reopens a question of responsibility architecture: GitHub detects and blocks, providers receive notifications, but no link in the chain guarantees that a publicly exposed credential will be deactivated within certain timeframes. The median of 784 days is not a technical delay, but a measure of the regulatory void in distributed secret management.

Information has been verified against cited sources and updated at time of publication.

Sources

Sources and references

Get DeafLetter