543,699 credentials published on GitHub still worked (2026 study): why you must revoke, not delete, and what developers should do

Who this is for: developers who keep code in public repositories such as GitHub, and companies that run APIs. This article restates the numbers from a security company's study in this site's own words. It does not cover how to find other people's credentials.

What this study is (not an official GitHub study)

On 29 September 2026, Truffle Security, a security company that sells secret-scanning tools, published a study of credentials left in public repositories. As a vendor of detection tools, the publisher has a commercial interest in the topic. This article uses the study's numbers as reported and marks this site's interpretation separately.

GitHub did not leak anything. The credentials were written into code and published by the owners of each repository. GitHub's role is to provide prevention features such as push protection (blocking pushes that contain secrets), and as shown below, those features cover a limited set of types.

How the study worked, and how to read the numbers

• The source data is The Stack v3, a dataset of public repositories collected by a third party for training LLMs (large language models). Collection closed on 7 August 2025.
• Only the default branch (such as main) at collection time was examined. Older commits, other branches and anything removed earlier are not included. It is not a scan of all public code on GitHub.
• "Live" means the provider confirmed the credential still authenticated on 27-28 July 2026. Some may have been revoked since.
• The time since exposure is counted from the last modification date of the file containing the credential. The study notes this tends to understate the real age.
• Some types are left out of certain figures. Google API keys were only tested against Gemini, and private keys cannot be tested without the host they belong to, so neither is included in the per-type survival figures.

The numbers: what was left, and how much

In the week of 29 February 2024, GitHub began turning on push protection by default for pushes to public repositories for all users. According to the study, 199,843 (36.8%) of the 543,699 live credentials appeared after that date.

In addition, 51.8% of the live credentials were connection strings, Google API keys or private keys, types that push protection does not block by default. For the types that push protection does cover, the number of leaks per million files fell by about 53% when comparing the 12 months before and after the change. Types it does not cover fell by only about 7%. The study itself notes other factors may be mixed in, such as cloud providers pushing customers toward short-lived credentials during the same period.

How many survived, by type

The table below recalculates percentages from the counts the study published. "Found" is the number of credentials found on default branches; "Live" is how many of those still authenticated at test time.

The detector used for MongoDB only records strings it managed to connect with, so no share can be calculated and the type is left out of the survival figures. Only the live count is reported.

Why the types differ so much

The difference comes less from how easy the credentials are to find and more from whether anyone stops them after they are found. Within what we could confirm in each provider's official documentation, the picture is as follows.

GitHub's secret scanning partner program notifies issuers about credentials found in public repositories. GitHub's documentation recommends treating any secret it reports as public and compromised, but leaves the implementation to the issuer. The issuer decides whether to revoke, reissue or contact the user.

The two cloud providers respond in ways that are not the same as full revocation.

• AWS: AWS attaches a managed policy called "AWSCompromisedKeyQuarantineV3" to an IAM user whose access key may have been exposed. It denies certain actions, such as launching instances or changing IAM, but does not delete the key. AWS asks customers not to remove the policy and to follow the instructions in the support case it opens.
• Google Cloud: since 16 June 2024, service account keys detected in places such as public repositories are disabled automatically by default. Organizations can opt out (WAIT_FOR_ABUSE) with the organization policy constraint iam.serviceAccountKeyExposureResponse. The study still found more than half live; it does not explain why.

If you find you leaked one

Preventing leaks

Push protection helps, but it is not enough on its own. As the numbers show, types it does not block by default pass straight through, and users can bypass a block by choosing a reason. Combine it with the following.

• Scan before you commit: stop secrets on your own machine before the push with a scanner such as gitleaks (see stop secrets before they commit with gitleaks).
• Scan the history of old repositories: push protection does nothing for commits made before it was turned on. Scan the full history of neglected and archived repositories at least once.
• Use short-lived credentials: GitHub Actions can connect to AWS or Google Cloud with OIDC (receiving a credential valid only for a short time on each run) instead of storing a long-lived key. Hugging Face offers the same approach.
• Narrow what each key can do: read-only, specific APIs only, source IP or referrer restrictions, and an expiry date. This limits what a leak can cost you.
• Keep databases off the internet: a leaked connection string is useless if it cannot be reached from outside. Database connection strings were the longest-lived type in the table.

The basics of keeping secrets out of code are in what's actually dangerous about .env and API keys, and secrets left on web servers are covered in auditing public directories.

For companies that run APIs

What separated the top of the table from the bottom was whether the issuer stops leaked keys automatically. As the party that protects your users' keys, consider:

• Joining GitHub's secret scanning partner program, and revoking valid keys and notifying users when you are notified
• Giving keys a distinctive prefix (for example, one that starts with your service name) so they are easy to detect
• Offering a channel or API through which anyone can report and invalidate a leaked key
• Making expiring keys and narrowly scoped keys the default

Sources (public record)

The numbers in this article come from the public sources below. We have not reproduced the study's text or charts; we used only its counts and reorganized them.

• Study by Truffle Security (a provider of secret-scanning tools), 29 September 2026 — trufflesecurity.com
• Coverage: BleepingComputer (30 September 2026) / SecurityWeek (1 October 2026) / GIGAZINE (2 October 2026, Japanese)
• GitHub: push protection on by default (GitHub Blog) / About push protection / Supported patterns / Partner program / Token expiration and revocation
• npm: npm Blog (18 June 2019)
• Hugging Face: User access tokens (revoking a leaked token)
• AWS: AWSCompromisedKeyQuarantineV3
• Google Cloud: Automatically disabling leaked service account keys (16 May 2024) / Best practices for managing service account keys

Read next

• Prevent: Stop secrets before they commit with gitleaks / Secret leak checker (paste to scan)
• Basics: What's actually dangerous about .env and API keys / What is a .env file
• What a leak can cost: AI-written code leaked an API key and ran up fraudulent charges
• Attacks that target developer credentials: Defending against supply-chain worms / The TanStack, Nx Console and GitHub compromise chain (May 2026)
• Narrow key permissions: SSH key least privilege