Decoding the world of cybersecurity

·

Public GitHub credentials remain live for years

Truffle Security says it verified 543,699 working credentials in a snapshot of 224 million public GitHub repositories, with a median exposure age of 784 days.

Public GitHub credentials remain live for years
Summary
  • Researchers verified 543,699 credentials that still authenticated when tested in July 2026.
  • The median exposed credential had been public for 784 days, while the oldest dated to 2009.
  • The research identifies credential revocation, rather than detection alone, as the persistent control gap.

More than half a million credentials embedded in public GitHub repositories were still valid when researchers tested them, exposing a long-lived gap between detecting leaked secrets and actually revoking them.

Truffle Security analysed a snapshot of 224 million public GitHub repositories assembled for AI-model training and said it verified 543,699 credentials that still authenticated when tested in July 2026.

The median credential had been exposed for 784 days. The oldest identified credential dated to 2009 and remained functional more than 16 years later.

The research used The Stack v3 dataset rather than a real-time crawl of every current GitHub repository. Truffle Security also measured credential age from the last modification of the file containing a secret because the dataset does not contain complete commit histories.

Those methodological limits do not remove the central finding: a substantial number of secrets in public code remained technically valid long after exposure.

The researchers also examined GitHub push protection. Credential types covered by default protection saw roughly a 53% reduction in the rate at which secrets reached public code during the following 12 months, compared with a 7% decline for types that were not covered by default.

Yet just under 200,000 credentials that remained live had been pushed after default push protection was introduced. Truffle Security said 51.8% of the live credentials it identified were in forms the default protection did not recognise.

The findings separate two security problems that are frequently treated as one. Secret scanning and push protection attempt to prevent or identify credentials entering source repositories. Revocation determines whether a credential can still be used once exposure occurs.

Removing a key from the latest version of a repository does not reliably end that risk. Public source code can be copied, forked, indexed, archived, scraped, and incorporated into model-training or analysis datasets, leaving historic versions outside the organisation’s control.

Revocation or rotation is therefore the control that invalidates the underlying access. Detection without revocation may reduce visibility of a leaked secret in the current repository while leaving the same credential usable by anyone who already copied it.

The study also intersects with non-human identity management. API keys, service accounts, database credentials, and automation tokens often lack the lifecycle controls applied to employee identities. They can persist through staff changes, project closures, and infrastructure migrations because no individual is prompted to review them regularly.

AI development creates another route through which old public code can be replicated. Large code corpora are used for training, retrieval, testing, and developer tooling, increasing the number of systems in which historical repository material may exist.

Truffle Security did not publish the repositories containing credentials that still worked, avoiding disclosure of live access material. Its research nevertheless indicates that the useful lifetime of a leaked secret can extend years beyond the original commit.

The control problem is therefore not simply whether organisations can detect strings that resemble credentials. It is whether the identity represented by that credential is disabled when exposure is confirmed.

Where that final step remains manual or has no clear owner, public disclosure can persist for years without actually removing the underlying access.

×