Public GitHub Code Still Contained 543,699 Working Credentials

Truffle Security identified 543,699 unique credentials in public GitHub repositories that remained accepted by their issuing services when tested at the end of July 2026.

The result exposes a gap between detecting a published secret and making that secret unusable. API keys, service-account credentials, tokens and database connection strings can continue providing access until an owner or service provider rotates or revokes them.

The analysis used a dataset assembled to train large language models. According to BleepingComputer’s report on the research, the underlying crawl covered 224 million repositories and more than 58 billion files before closing on August 7, 2025.

SecurityWeek reports that the scan found 1,103,438 exposed credentials overall. Truffle subsequently determined that 543,699 were still active. The research measured public exposure and continued validity, not whether attackers had discovered or exploited each credential.

Some credentials remained public for years

The median unique credential remained publicly accessible for 784 days. About 10% of the working credentials were more than 6.3 years old, while one quarter of the credentials found were older than four years.

Some were considerably older. Truffle found 2,636 active credentials in files last modified before 2015. The oldest was an AWS key committed in 2009 and left untouched afterward, according to SecurityWeek.

These figures make historical code a central part of the exposure problem. Truffle located credentials in repositories and files numbering more than 1.1 million, with copies in forks included. Removing a secret from the current version of a project therefore does not address every location where it may have appeared.

Deletion also does not revoke the underlying credential. If the issuing service continues accepting the original value, a copy retrieved from an earlier public file or repository can remain usable.

The density of working credentials increased over the period measured. Truffle recorded 3.72 active credentials per million files in 2015, rising to a peak of 11.62 per million files in 2025.

The GitHub findings also exceeded the results of Truffle’s earlier Hugging Face analysis. That scan found 221,303 working credentials, less than half the number reported in the GitHub dataset.

Validity rates differed sharply between credential types

The likelihood that an exposed secret still worked varied substantially by category and issuing service.

Of 126,963 exposed Google Cloud service-account credentials, 69,041 remained valid. SecurityWeek described this as the largest listed category of active credentials. Other reported categories included:

• 51,067 active MongoDB connection strings
• 33,343 live Google API keys
• One working npm token out of 101,886 committed npm tokens

The npm figure contrasts sharply with the other categories. Almost all committed npm tokens in the dataset had stopped working, while tens of thousands of Google Cloud credentials, MongoDB connection strings and Google API keys still responded.

Provider-side revocation practices help determine how long an exposure remains dangerous. GitHub can detect or report certain secrets, but it cannot independently invalidate credentials issued by another service.

The reports do not detail the access rights attached to each working credential. The 543,699 figure therefore cannot be treated as a count of compromised accounts, systems or cloud environments. Each secret exposes only the resources and privileges granted to it, which can vary widely.

Even so, continued validity creates an opportunity for unauthorized access. A publicly accessible credential does not need to be technically bypassed if the corresponding service still recognizes it.

Push Protection reduced exposure only within its coverage

GitHub’s Push Protection scans incoming code for recognizable secret patterns, such as API keys and access tokens. When it identifies a supported secret, it can block the push before the credential becomes public.

BleepingComputer reports that the feature was introduced for Advanced Security users in April 2022 and became available for public repositories in May 2023. It also says GitHub activated Push Protection for all users in February 2024. Another rollout description in the same report does not align precisely with those dates.

Truffle separated the active credentials into three groups:

• 245,959 predated free secret-scanning alerts.
• 97,897 appeared while scanning was free but Push Protection was not yet enabled by default.
• 199,843 were exposed after blocking became the default.

The final group accounted for approximately 36.8% of the active total. Nearly 200,000 credentials published during the default-blocking period were consequently still accepted when Truffle tested them.

That result does not mean the control was ineffective. For credential categories covered by Push Protection, the exposure rate fell by 53% after the feature became enabled by default. The reduction applies only to protected categories, not to credential exposure as a whole.

Coverage is a significant limitation. BleepingComputer reports that 51.8% of the live credentials belonged to categories not blocked by GitHub’s default Push Protection, including database connection strings and Google API keys.

Push Protection also addresses new attempts to publish supported secrets. It does not revoke credentials exposed before the control intervened.

Secret alerts still require action from owners and providers

GitHub operates a secret-scanning program that sends exposed tokens to the services that issued them. However, GitHub does not require those providers to revoke the reported credentials.

Truffle attributed part of the continuing exposure to providers that may lack a process for invalidating leaked tokens. As described in SecurityWeek’s coverage of the findings, historical alerts also depend on repository owners enabling them, reviewing the results and rotating the affected credentials.

This creates several points where remediation can stop:

1. GitHub or another scanner must recognize the credential.
2. An alert must reach the repository owner or issuing provider.
3. Someone must assess the finding.
4. The exposed credential must be revoked or rotated.

Detection alone leaves the credential functional. Removing the string from visible code without invalidating it has the same limitation.

The findings also need to be interpreted carefully. Truffle verified that the credentials were exposed and still working, but the research did not establish what proportion had been stolen or abused by attackers.

Rotation and historical scanning are the immediate priorities

Truffle’s recommendations begin with immediate rotation of exposed credentials. Organizations should treat public disclosure as a credential-lifecycle incident rather than only a code-cleanup task.

Affected teams should:

1. Rotate exposed credentials immediately. The published value must stop working at the issuing service.
2. Remove secrets from repositories. This reduces continuing visibility but does not replace revocation.
3. Scan repository history. Checking only the current version can miss credentials contained in earlier files or commits.
4. Configure automatic expiration. Time-limited secrets reduce the period during which an overlooked exposure remains usable.
5. Use Push Protection and secret-scanning alerts. These controls can block or identify supported secret types, but they must feed into a functioning rotation process.

Repository reviews should account for forks and repeated copies identified during an investigation. Teams should also examine the relevant provider logs for activity involving exposed credentials, because the aggregate research does not determine whether any particular organization’s secrets were misused.

The two published reports do not list the credential values or affected repository URLs. Organizations must therefore inspect their own public code, repository history and credential inventories rather than wait for a universal list of exposed secrets.

The central problem is not merely that developers committed sensitive values. It is that hundreds of thousands of those values remained operational, in some cases years after they first became publicly accessible.