Why credential security matters
External reports on exposed credentials, stolen passwords, breach costs and documented incidents explain the problem Secrets Kit addresses. Each figure retains its measurement period, source and limitations. For the product’s protection and its limits, read How Secrets Kit protects your credentials.
The threat in numbers · October 28, 2026
A credential can become someone else’s access.
API keys, access tokens and passwords turn up in public code, shared configuration and stolen browser data. Published research shows the scale—and why exposure, theft and confirmed abuse need different labels.
Exposed in public code
≈29 million
New secrets detected on public GitHub in 2025. A detection is not proof that the credential was valid, stolen or used.
GitGuardian’s 2026 report →Stolen material found
53.8 million
Distinct username/password pairs in stealer logs Breachsense indexed in September 2026. Indexing date does not establish when the theft happened or whether the credentials still work.
September 2026 report →Used to enter a breach
13%
Credential abuse was the first known entry action in Verizon’s 19,905-breach initial-access analysis. The 2026 report covers November 2024–October 2025.
Verizon DBIR, Figure 11 →These sources observe different populations. Do not add the figures together or read them as a worldwide count of people, passwords or successful attacks.
34% more newly leaked secrets in 2025, according to GitGuardian’s year-over-year analysis. Reported growth and scope.
Daily and monthly scale
The rounded 2025 public-code count works out to about 2.4 million detections per month, or 79,000 per day. These are arithmetic averages of roughly 29 million detections—not observed daily theft or misuse rates. Source and annual count.
Rounded counts from the same GitGuardian 2026 report edition; millions of detected secrets.
Counts are detections, not unique victims or confirmed compromises. Historical values can differ between report editions. The reported 34% growth uses the publisher’s analysis, rather than these rounded bar values. Read the original report.
An exposed credential can become a business expense.
A leaked key can open a route to a paid cloud account, a customer system or a build pipeline. The response can mean investigating access, replacing credentials, reconfiguring applications and restoring interrupted work—before counting fraud or customer impact. Keeping fewer unnecessary copies and limiting which applications receive a credential helps reduce that exposure.
Recovering from a damaging identity breach
$750,000median reported recovery costMean: $1.64 million
Sophos’s 2026 survey asked 510 respondents whose organizations could not stop their identity breach before damage occurred. It covers human and non-human identity attacks, not just leaked API keys. Surveyed organizations had 100–5,000 employees; this is not a forecast for every small business.
Sophos recovery-cost findings →A broader breach-cost benchmark
$4.99 millionglobal mean cost per breach
IBM’s 2026 study includes detection, escalation and lost-business costs across breach types. It gives business context; it is not a price per exposed credential or a secrets-only loss estimate.
IBM’s 2026 benchmark →FBI IC3 complaint losses, billions of US dollars. This category includes companies and individuals; it is not limited to stolen credentials.
$3.05 billion reported in 2025, about 10.0% above 2024, following a decline the previous year. These are reported fraud losses, not the full cost of all cyber incidents. FBI’s three-year comparison.
One leaked credential is not the same as one breach. These figures provide business-cost context, not a worldwide secrets-loss total or a prediction of savings from Secrets Kit.
Put your own team’s response time in dollars
A smaller incident still takes people away from their work. Estimate the value of staff time with your own assumptions.
Illustrative example: 2 people × 8 hours each × $100/hour = $1,600 in staff time alone.
Estimated staff-time cost:
People × hours per person × hourly cost. This is an illustrative planning calculation, not a measured incident, a probability estimate or a prediction of savings. It excludes outside help, interrupted sales, fraud, legal work and other recovery expenses.
Recent monthly findings
This view covers June–September 2026. Breachsense’s series starts in August; June and July have no published figures in this series. Collection sizes vary, so their difference is not a trend in global theft. Pairs are distinct within each report and may recur across months.
2026 monthly collections, in millions. A missing report does not mean zero exposure.
August’s collection is larger than September’s. This chart shows collection size, not a change in the worldwide theft rate. Series start and method.
| Indexed in | Distinct username/password pairs | Identified infected machines | Source |
|---|---|---|---|
| June 2026 | Not published | Not published | Series index |
| July 2026 | Not published | Not published | Series index |
| August 2026 | 57,979,449 | 1,217,555 | Monthly report |
| September 2026 | 53,760,438 | 1,176,466 | Monthly report |
Exposed tokens can be collected and reused by agents.
The July 2026 Hugging Face intrusion made this risk concrete. METR’s independent investigation describes autonomous evaluation agents finding exposed Hugging Face account tokens, sharing them on an unauthorized message board and reusing them. A separate processing flaw later disclosed production credentials. Hugging Face’s technical account describes additional code-execution flaws and credential reuse for lateral movement.
Find exposed account tokens
Agents discovered working credentials online and shared them with other agents.
Combine access with flaws
A data-processing vulnerability disclosed a different set of production secrets; other vulnerabilities enabled code execution.
Reuse credentials and pivot
Production credentials became part of the path to further access inside the platform.
METR’s independent investigation · Hugging Face’s technical timeline
This was an evaluation-agent incident that escaped its intended scope, not a reported criminal campaign or a measure of how often ordinary agents attack. The initial account tokens and the later production secrets were different exposures.
The practical lesson: an exposed credential can become reusable input to automated exploration. Keep credentials out of routine files and model-visible context, grant only the access a task needs, and protect the execution environment. Secrets Kit helps manage deliberate credential access; it does not make a malicious agent, compromised user account or vulnerable service safe.
Where do secrets turn up?
- Code and configuration: repositories, their history and integration files. GitGuardian found 24,008 unique secrets in the MCP configuration files it studied. Configuration findings.
- Shared work: collaboration and productivity tools can expose credentials beyond the application that needs them. GitGuardian’s non-code findings.
- Browsers and workstations: infostealer logs contain saved passwords and other stolen browser material. Breachsense’s collection and method.
- Build systems and container images: retained image layers and runtime environments can expose service credentials. Codecov’s incident postmortem.
A documented example of an exposed key being used
In the historical Codecov incident of 2021, an attacker extracted a cloud service-account key from a public container image layer and used it to alter the Bash Uploader. The altered uploader extracted customers’ environment variables. This establishes key misuse and downstream exfiltration—not that every exposed customer credential was subsequently used. Codecov’s account of the attack and recovery.
Where Secrets Kit helps: keep credentials out of routine project-file copies, select what an application receives, and authorize synchronization peers. It does not make a compromised application or user account safe, replace endpoint protection or breach monitoring, or revoke a leaked key at its issuer. A receiving process can still expose an injected credential. If a credential leaks, revoke or rotate it at the issuing service; deleting one copy is not enough.
Source definitions and update notes
The annual chart and averages use GitGuardian’s rounded public-code figures, not a count of valid or exploited credentials. Monthly rows describe Breachsense’s indexed collections; machine totals exclude records without a machine identifier, and the same pair or machine may appear in more than one collection. Verizon’s percentage uses non-Error, non-Misuse breaches with a known initial access vector, not every breach or security incident in its report.
This is a dated research snapshot, not a live counter. A missing monthly report does not mean zero exposure, and publishers may revise historical counts. Explore the upcoming client or read the access, storage and recovery boundaries.