543,699 GitHub Credentials Still Valid: Find and Rotate Your Exposed Secrets Now

Developers commit secrets to GitHub through a predictable set of mistakes: hardcoding credentials directly in application code, leaving API keys in configuration files checked into version control, storing database connection strings in test fixtures, and embedding cloud service account keys in CI/CD workflow files. Each mistake exposes the credential to anyone who accesses the repository, and in public repos that means the entire internet.

The problem compounds because git preserves history. Deleting a file from the current branch does not remove it from prior commits. An AWS access key committed three years ago and deleted in the next commit still exists in every clone of the repository and in every service that archived the repository state at that time. GitHub's default secret scanning operates on current-branch content; history scanning requires separate tooling.

Public training datasets amplify the exposure beyond GitHub itself. The Stack v3, a 7.6-petabyte dataset of public GitHub code used to train large language models, was scanned by Truffle Security in July 2026. Researchers identified and validated 543,699 credentials that remained live against production systems. These datasets are downloaded by researchers, developers, and organizations worldwide, meaning exposed credentials propagate to machines and environments far outside the original repository's reach.

AI coding tools introduce a newer leak vector. When developers ask coding assistants to generate configuration templates, environment setup scripts, or connection examples, the AI frequently produces code with real-credential formatting. Developers sometimes fill in actual credentials without adjusting git ignore rules or pre-commit scanning, then commit the result.

Truffle Security scanned 224 million repositories and 58 billion files in The Stack v3 dataset, then validated every candidate credential against its issuing service. The validation confirmed 543,699 unique credentials still authenticated on July 27 and 28, 2026.

The scale of the remediation failure is the most alarming finding. The median credential had been publicly accessible for 784 days -- more than two years -- before any action was taken. Ten percent of the live credentials had been exposed for at least 6.3 years. The oldest active credential had been functional for more than 16 years.

A GitGuardian revalidation study reinforces the pattern. 64% of credentials confirmed valid in 2022 were still valid when retested in January 2026, four years after their initial exposure. Revocation rates remain low because most organizations lack visibility into what leaked, when it leaked, and which services the credentials can access. Without active scanning, secrets discovered today stay live for years.

Hugging Face training datasets compound the exposure further. A separate Truffle Security scan of public Hugging Face datasets found 221,303 live unique credentials across 6,003 datasets, including 349 live GitHub tokens. Researchers and AI engineers who download these datasets for model training inadvertently receive valid credentials alongside the training data, creating secondary exposure vectors outside GitHub's security perimeter entirely.

AWS IAM access keys represent the highest-value target. A long-term access key with AdministratorAccess or PowerUserAccess policy grants control over entire cloud infrastructure -- S3 buckets, EC2 instances, Lambda functions, RDS databases, and IAM itself. Attackers use compromised AWS keys to exfiltrate data, create persistent backdoor IAM users, run cryptominers across every available region, and pivot to connected SaaS environments. AWS keys appear frequently in public repos because developers test them locally and forget them in environment variable files.

Google Cloud Platform service accounts are the second-highest value target. GCP JSON key files are frequently committed to infrastructure-as-code repositories and Terraform modules. A service account key with project Editor or Storage Admin permissions grants full data access and resource control. GCP service account keys do not expire by default, and they remain valid until explicitly deleted from the service account, meaning an exposed key from three years ago can still work today.

MongoDB connection strings provide direct, authenticated database access. A connection string in the format mongodb+srv://user:password@cluster.mongodb.net/dbname gives an attacker immediate read and write access to all collections in the target database without any additional exploitation steps. AI service credentials -- OpenAI, Gemini, Anthropic -- are consumed for inference at the victim's billing cost, with some cases reaching five-figure charges within hours of credential discovery.

Private RSA and EC keys are the longest-lived exposure category. An SSH private key committed to a repository grants access to every server configured to trust the corresponding public key. Unlike API tokens with auditable usage logs, SSH connections blend with legitimate traffic and are difficult to detect retroactively.

GitHub push protection was designed to intercept high-confidence, low-false-positive secret types at the moment of commit -- specifically tokens with fixed prefixes and strong checksum properties, like GitHub personal access tokens and AWS access keys in the format AKIA[A-Z0-9]{16}. The feature works as intended for the categories it covers. The 543K finding reveals where the coverage ends.

36.8% of the confirmed-live credentials were exposed after push protection began rolling out as a default, meaning they were committed by developers who bypassed the protection, fell into categories push protection does not block, or existed in private repositories later made public. 51.8% of live credentials fall into categories push protection does not block by default: generic database connection strings, private RSA keys, and many Google API keys without recognizable prefixes.

Historical commits receive no retroactive protection. A key committed two years ago and never deleted from history is invisible to push protection. Organizations that enabled the feature recently have no coverage for credential exposure that predates activation.

Private-to-public transitions bypass all pre-commit checks. A developer who stores credentials in a private repository and later changes the visibility to public exposes every historical commit instantly. GitHub's secret scanning can detect and alert on this transition, but only if the alert is reviewed and acted on promptly -- and the 784-day median exposure time suggests most are not.

These rules detect credential scanning tool execution and cloud metadata service probing -- the two behaviors most directly linked to attackers validating stolen GitHub credentials. Both carry experimental status; validate against your environment's log format before enabling automatic blocking.

Every organization with public GitHub repositories or developers who have contributed to public projects should treat this as an active incident requiring immediate action. Automated credential scanners have already processed The Stack v3 and its derivatives. If your credentials appear in this dataset and are not revoked, assume they are known to threat actors.

The sckit supply chain worm campaign published September 25 demonstrated that developer credential theft is an active criminal priority, with attackers compromising npm and PyPI packages to steal credentials at build time. Public GitHub repositories extend that attack surface to any code ever committed by any developer, making proactive scanning non-negotiable.

The secrets sprawl problem represents a durable, low-noise attack surface that requires no zero-day exploit and no social engineering. An attacker needs only to download a public training dataset and run a validator against the credentials found. At 543,699 confirmed-live credentials and 29 million new secrets hitting GitHub annually, the probability that an organization with any public GitHub presence has at least one exposed credential is not theoretical.

MITRE ATT&CK maps this threat to T1552.001 (Credentials in Files) and T1078 (Valid Accounts). The attacker obtains valid credentials through passive collection from public sources, then uses those credentials to access cloud systems directly. There is no initial intrusion phase, no vulnerability to patch, and no alert from a perimeter control. The first sign of compromise is often billing anomalies in AWS or GCP, unexpected API calls in application logs, or a threat intelligence feed flagging your organization's cloud account ID in attacker infrastructure.

The 784-day median exposure time reveals an organizational pattern: most teams discover exposed credentials only when something goes wrong. Proactive rotation cadences and continuous scanning replace reactive discovery. Organizations that scan for exposed cloud credentials and enforce short key lifetimes reduce the window between exposure and detection to days, not years.

The 81% year-over-year increase in AI service credential leaks signals that the problem is accelerating alongside AI adoption. Every new AI API key, every new model provider integration, and every AI coding tool session is a potential credential leak vector. Secrets hygiene is now an AI security requirement, not just a developer operations best practice.