# Leaked secrets in public repos: October 2026 data — LeakWatch > We scanned public GitHub and GitLab commits for 21 days and checked every credential against its provider. 1,106 were still live. Here is what they were. Source: https://leakwatch.net/blog/leak-data-report-october-2026 --- [← Blog](/blog) # What we found scanning public commits in October 2026: 1,106 live credentials, 858 repositories October 21, 2026 · 0xCr0c0 · 10 min read Between 1 and 21 October 2026, LeakWatch scanned commits as they were pushed to public repositories on GitHub (including Gists and the GH Archive feed) and GitLab. Every credential that had a matching validator was tested against its provider’s own API. The short version: **1,106 credentials were confirmed live, spread over 858 repositories.** That is about 55 a day. This post gives the numbers, and — as importantly — what they do and do not mean. ## The headline numbers October 1–21 Candidate secrets flagged (after false-positive filtering) 46,023 Credentials tested against their provider 6,434 **Confirmed live** **1,106** Repositories with at least one live credential 858 Of which rated critical or high severity 1,059 (96%) *From flagged to proven: about one tested credential in six was still accepted by its provider.* Of the 1,106, 510 are rated critical and 549 high. Only 47 are medium or low. We count a credential as “live” only when the provider’s API accepted it: a database that answered the connection, a bot token that returned its bot, an API key that listed its models. Everything else is listed separately below, so the headline is not padded. ## What leaked Live credentials by type: Type Live Share Database connection strings 387 35% Telegram bot tokens 300 27% Cloudinary keys and secrets 86 8% Groq API keys 82 7% DeepSeek API keys 58 5% Gemini API keys 42 4% Razorpay keys 32 3% ElevenLabs API keys 27 2% GitLab personal access tokens 23 2% OpenRouter API keys 19 2% Databases & bot tokensAI providersOther servicesRemaining types *Live credentials by type, 1–21 October 2026. “All other types” groups 50 credentials across smaller categories.* Three things stand out. **Databases and bot tokens are 62% of everything.** A connection string is the most expensive thing to leave in a repository: it usually carries host, user, password and database name in one line. A Telegram bot token is cheap to leak and gives full control of the bot. **AI provider keys are a large and fast-moving category.** Groq, DeepSeek, Gemini, ElevenLabs, OpenRouter and OpenAI keys together account for 233 live credentials. Unlike a database, an AI key has a direct price: whoever finds it spends the owner’s credit. **Cloud-provider keys are comparatively rare.** AWS access tokens, GitHub tokens and Google API keys each appear only in the single digits. ## Where they came from Candidate secrets that survived filtering, by source: Source Candidates Live credentials GitHub live event stream 29,553 691 GitHub, via GH Archive 13,435 303 GitLab 2,458 89 GitHub Gists 577 23 Among credentials we could test, 17% turned out to be live: 16.5% on GitHub and 34% on GitLab. The GitLab sample is small (262 tested credentials), so we would not read much into that gap yet. We saw no findings from Codeberg in October. ## Many of them don’t stay live For 938 of the live-type credentials, we re-tested the key after the first check. **404 of them, 43%, were already dead on the re-test.** The owner had revoked or rotated them. Dead on re-testStill live at last re-test *The 938 live credentials we re-tested, by status at their last re-test.* That is encouraging, but read it carefully: we know a key was dead at the second check, not how quickly. The other 534 were still live at the time of their last re-test. ## What we left out of the headline Some findings pass a validator without being a live secret. We report them, but do not count them: - **1,723 AWS ARNs.** An ARN is an identifier, parsed statically. It is not a credential and could not be used to authenticate. - **319 private keys** across 231 repositories were parsed as well-formed keys. We did not prove that they grant access to anything, so they are not counted as live. - **28 test-mode keys** (for example Stripe test keys), which are meant to be public. Counted as livePassed a validator, not counted *Findings that passed a validator. Only the first bar is in the headline.* If you count all three, the number would be 3,176. We think 1,106 is the honest one. ## How we filter noise The detection pipeline is a regular-expression engine followed by a language-model check that discards likely false positives. From 16 to 20 October, **82% of raw candidates (17,424 out of 21,244) were rejected** by that check. Rejected as false positiveKept *Raw candidates from 16 to 20 October, by verdict of the language-model check.* That is why a raw count of “secrets found” is a poor measure of anything: most of what looks like a key is not one. Before 15 October we did not keep rejected findings, so the 46,023 candidates above include some that the filter would now discard. This is another reason to look at the confirmed-live number rather than the candidate count. Of the retained candidates, 28,622 have no validator for their type, and 8,750 hit a validator error (typically a timeout or a rate limit). They are not counted as live or dead. ## Why we don’t compare with September Our scan volume stepped up sharply on 6 October, from a few hundred findings a day to roughly 4,000. A month-over-month “growth” figure would measure our own coverage, not an increase in leaks, so we have not published one. ## Limits - **We only see public commits.** Private repositories are out of scope. - **Coverage is partial.** The event streams we read are not exhaustive, and some commits are missed. - **“Live” means live when we tested.** It is a point-in-time fact, not a lasting one. - **Counts are findings, not people.** One repository can hold several findings, and one person can own several repositories. We report repositories, and make no claim about the number of individuals affected. - **The period is 21 days, not a calendar month.** The data ends on 21 October. ## What to do about it If you found this because you worry about your own repositories: 1. Revoke the credential at its provider first. Deleting the commit does not help, since the key may already have been copied. 2. Remove it from history only after that: see [what to do when you push an API key](/blog/i-accidentally-pushed-an-api-key-to-github). 3. Scan your whole history, not only the latest commit: see [deep scan](/blog/deep-scan-your-whole-git-history). We never publish the names of the repositories or people behind these numbers, and the alert we send to an affected maintainer is free. ![Gabriel Diyan, founder of LeakWatch](/brand/Photo-Gabriel-Diyan.webp) Gabriel Diyan (0xCr0c0) Cybersecurity student, founder of LeakWatch. I built and run the scanner described here — the detection patterns, the false-positive classifier and the provider validators are mine. [More about who I am](/about). [GitHub](https://github.com/Leakwatch-Scan) · [X](https://x.com/LeakwatchScan) · [LinkedIn](https://www.linkedin.com/in/gabriel-diyan-80a378375) · [GitHub (personal)](https://github.com/crocogab) Are your own keys in public repositories? Type a GitHub, GitLab or Codeberg username and see in seconds — free, read-only, nothing stored. [Check your account](/) LeakWatch Secrets leak into public commits every minute. This watches the forges for yours. Built and run by [Gabriel Diyan](/about), a cybersecurity student — [why LeakWatch exists](/about). Scan - [Product](/product) - [Live feed](/leaks) - [Trends](/leaks/trends) - [API docs](/docs) - [CI/CD](/docs?tab=ci) Read - [Blog](/blog) - [Secret guides](/secrets) - [Changelog](/changelog) - [About](/about) Verify - [Security](/security) - [Privacy](/privacy) - [Terms](/terms) - [Legal](/legal) - [Contact](/contact) - [Status](https://status.leakwatch.net) © 2026 LeakWatch [GitHub](https://github.com/Leakwatch-Scan)[X](https://x.com/LeakwatchScan)