Stripe Merchant API Key Exposure Put 688,363 Customer Records at Risk

The August 18, 2026 release was best understood as a merchant-credential exposure rather than a confirmed Stripe platform breach. Reports described a free archive of roughly 35 GB containing 17,654 files from 659 merchant accounts and information linked to an estimated 688,363 customers in 42 countries. Those figures are reported estimates, and some broader claims made by the threat actor have not been independently verified.

What the archive reportedly contained

The material was described as covering records from January 2022 through June 2026. Reported data types included:

• Stripe customer objects and customer contact information
• Charges, payment intents, Checkout sessions, invoices, refunds and disputes
• Payouts and balance transactions
• Subscriptions, products and prices
• Payment-related metadata, including card brand, last four digits, expiry, funding type, issuing country and payment fingerprint

The reporting did not indicate that the archive contained complete card numbers. That limits some forms of direct card theft, but it does not remove the risk created by exposed API credentials and detailed customer and transaction data.

Researchers reported finding 650 live sk_live secret keys and nine restricted keys. Of the affected accounts, 573 could accept payments, 531 could make payouts and 519 could do both, according to the analysis cited in the reporting.

Why a single live key could be serious

A Stripe secret key is an API credential, not merely an identifier. Its effective reach depends on the key’s permissions and the merchant’s account configuration, but a compromised credential can expose merchant resources and enable unauthorized payment activity.

Testing described in the reporting showed that one active key could be used to access customer lists, create fraudulent payment links and make test charges. Potential consequences included customer-data enumeration, payment abuse, unauthorized refunds, targeted phishing and payment-related social engineering. Accounts with payout capabilities faced an additional need to verify payout settings and destination details.

The practical risk is speed: an exposed server-side credential can turn a secret-management failure into a live fraud investigation before a merchant notices unusual activity.

Why researchers did not classify it as a Stripe infrastructure breach

The available evidence suggested that attackers used valid merchant credentials to retrieve Stripe data through legitimate API access. Researchers examining the released files offline said the Stripe-style objects and directory structure were consistent with exports from API endpoints; they did not authenticate with the exposed keys or access the merchants’ live environments as part of that review.

That distinction matters. It shifts the likely control failure from Stripe’s core systems to the places where merchant secrets may be stored or exposed, including:

• Infostealer infections on developer or administrator devices
• Public repositories and historical Git data
• Exposed .env files and server configuration
• Cloud storage, backups and container layers
• CI/CD systems and GitHub Actions logs
• Misconfigured servers or automated scans for exposed variables

The initial theft path for the 659 merchant credentials has not been established. These are plausible exposure routes, not a confirmed single origin for the entire dataset.

The related release and the numbers caveat

Hudson Rock reporting attributed a related forum release to the same actor. That release was described as involving 669 vendor folders and 1,033 compromised API keys, with an advertised size of 33 GB; the linked download was reportedly smaller. The actor also claimed to possess roughly 20,000 additional compromised Stripe API keys and suggested that more batches could follow.

Those figures should not be combined into one verified total. The differences between 659 merchant accounts, 669 vendor folders and 1,033 keys may reflect different datasets, duplicate or multiple keys per account, and different counting methods. The 20,000-key figure remains an unverified claim by the actor.

Where the reported merchants were located

The leading affected locations in the available reporting were:

• United States: 212 merchants
• United Kingdom: 81
• France: 57
• Canada: 38
• Brazil: 30
• Australia: 27

These counts describe the reported merchant distribution and should be read alongside the broader caveat that the dataset’s scope was still being assessed.

What Stripe businesses should do now

1. Rotate live secret keys

Revoke and replace every live secret key that may have appeared in source code, logs, backups, endpoint telemetry, container images or public infrastructure. Do not wait for evidence of fraudulent activity before rotating a potentially exposed credential.

2. Audit API activity and payment operations

Review API and security logs for unfamiliar calls, new payment links, test or unauthorized charges, unexpected refunds, permission changes and unusual source IP addresses. Preserve relevant logs so investigators can establish a timeline.

3. Verify payout configuration

Check payout settings, connected bank-account details and payout destinations. Escalate suspicious changes to Stripe and financial institutions promptly, following the applicable incident-response and reporting procedures.

4. Replace broad credentials with restricted keys

Use restricted keys scoped to the smallest set of API operations required by each service. Separate production systems, development environments and operational roles rather than distributing one broad secret across multiple applications.

5. Search every place secrets can persist

Search current and historical repositories, Git history, CI/CD output, GitHub Actions logs, .env files, container layers, cloud storage, documentation and backups for sk_live values. Any discovered credential should be revoked and replaced, even if it no longer appears in the current version of the code.

6. Treat GitHub scanning as one layer—not full coverage

GitHub says secret scanning runs automatically for public repositories, while organization-owned private and internal repositories require GitHub Secret Protection on eligible plans. Scanning also cannot recover secrets already copied into logs, backups, endpoint telemetry or downloaded archives. It should complement, not replace, centralized secret management, short credential lifetimes, access controls and continuous monitoring.

The main lesson for merchants

The incident’s clearest takeaway is that payment-platform security depends partly on merchant credential hygiene. The available reporting does not establish a breach of Stripe’s infrastructure, but it does show how exposed live API keys can provide a path to customer-data access and payment abuse. Treat production secrets as high-impact credentials: keep them out of code and logs, restrict their permissions, rotate them quickly and investigate every unexpected API or payout event.