Stripe Merchants: Leaked Live API Keys and Mass Customer Data Exposure

A dataset posted for free download on a data-trading forum on 18 August 2026 exposed live Stripe secret API keys belonging to hundreds of merchant accounts, along with roughly 35 GB of customer and payment data pulled directly through those keys. The material was first analysed by researchers at Ransomnews, whose findings were subsequently picked up by Security Affairs, Cyber Security News, CybersecAsia, Cyber Insider, CryptoBriefing and others. Reported credential counts vary by source: Ransomnews, Security Affairs and Cybersecurity Times describe keys for 659 merchant accounts, while Cyber Insider and CybersecAsia break that down further as 659 validated credentials of which 650 were live sk_live secret keys and nine were restricted keys. MarketBrief leads with the 650 live-key figure. Customer record counts are consistent across sources at 688,363, rounded to "roughly 688,000" by Cyber Security News and Cyber Insider. Critically, and consistently across every source reviewed, Stripe's own infrastructure was not breached. Readers should note that no primary-tier documentation exists in this source set: there is no direct Stripe advisory, regulator filing or CERT bulletin among them, and Stripe's position is relayed secondhand throughout.

What Happened

The listing went up in the early hours of 18 August under a headline claiming Stripe itself had been hacked. Ransomnews states plainly that this framing is wrong, and forensic review reported by Cybersecurity Times reached the same conclusion: the archive is a collection of individual merchant API exports, not evidence of a centralised intrusion at the payment processor.

The seller uses the handle "Satanic," described by Ransomnews as an established forum account with 779 posts and a reputation score approaching 2,000, which has posted leaked databases and credential lists steadily through 2026. CryptoBriefing identifies the venue as PwnForums; other sources describe it only as a data-trading forum. Rather than monetising the archive through private sale, the actor released it publicly at no cost.

Ransomnews says it analysed the files offline, avoided accessing the live payment records themselves, and notified Stripe before publication. Cyber Security News confirms this disclosure sequence in the report shared with it.

The exposure sits inside a much larger problem. Separate Ransomnews research covered by Security Affairs documented more than 50,000 unique Stripe merchant API keys exposed across public code repositories, GitHub Actions logs and misconfigured web servers, the majority of them live-mode secret keys. Both CybersecAsia and CryptoBriefing report that the same threat actor claims to hold roughly 20,000 additional keys not included in this dump, to be released in later batches. That claim is unverified and comes from the actor themselves.

What Was Taken

The archive spans 17,654 files totalling approximately 35 GB, though CryptoBriefing gives a range of 33 to 35 GB. It contains 688,363 unique customer records drawn from merchants in 42 countries.

Geographic concentration, per Cybersecurity Times and CybersecAsia: the United States accounts for the largest share at 212 merchants, followed by the United Kingdom (81), France (57), Canada (38), Brazil (30) and Australia (27).

Each merchant is given its own folder containing up to 27 distinct Stripe resource types, including customers, charges, payment intents, checkout sessions, invoices, payouts, balance transactions, refunds, disputes, subscriptions, products and prices. Several folders also contain customers_expanded and charges_expanded variants, which is what the API returns when called with expansion parameters. The collector was methodical. Records date from 4 January 2022 through 1 June 2026.

Every folder also carries a file that is not a Stripe object at all: the collector's own index, recording the key used, a hash of that key, and the capabilities it carried. That metadata is what makes the dataset dangerous rather than merely embarrassing. Per MarketBrief and Cyber Insider, it shows 573 accounts able to accept payments, 531 able to make payouts, and 519 with both capabilities.

MarketBrief reports that Stripe stated no full credit card numbers were present in the leaked dataset. That specific claim appears in only one source in this set and should be treated as attributed rather than independently confirmed.

Why It Matters

An account with both payment-acceptance and payout capability is a money-movement channel, not just a data store. The 519 accounts holding both permissions represent the sharp end of this incident: an attacker holding such a key can pull funds in and push funds out through infrastructure the merchant's own fraud controls are configured to trust.

This is a machine-identity failure, not an application-login failure. As Cyber Insider notes, Stripe has separately warned that possession of an API key allows an unauthorised party to impersonate the merchant account outright. Secret keys carry no MFA, no session expiry, no device binding and typically no anomaly alerting. They are bearer tokens with the full authority of the account.

The blast radius extends past the 659 merchants named here. The 50,000-key figure documented by Security Affairs suggests this dump is a sample of a much deeper pool of exposed credentials, and that any organisation with sk_live keys in its history should assume it is in scope until proven otherwise.

There is also a governance problem. CryptoBriefing points out that Stripe's terms of service place responsibility for securing API keys squarely on the merchants who generate them. Stripe provides rotation tooling and restricted-key options, but the liability sits merchant-side, which means the 688,363 affected individuals are downstream of hundreds of separate organisations with wildly varying security maturity and no coordinated notification mechanism.

The Attack Technique

There is no exploit here. Ransomnews and CybersecAsia both describe the same mechanism: someone obtained merchant secret keys, tested them, and then issued ordinary, entirely legitimate Stripe API requests to retrieve whatever each account's permissions allowed. No vulnerability in Stripe's core systems was involved.

On how the keys were harvested, sources broadly agree but do not fully converge. Security Affairs and CryptoBriefing cite public and accidentally-public GitHub repositories, GitHub Actions logs, infostealer malware and misconfigured web servers. CybersecAsia adds exposed .env files, misconfigured backups and CI/CD logs to the list, but notes an important caveat: no infostealer infections have been tied to the specific vendor domains involved. CybersecAsia further reports that some researchers theorise the attacker may instead have run automated bots to crawl for publicly exposed environment variables and weakly secured secrets. Accounts differ on the collection method, and the honest position is that harvesting is plausible via several routes with no single one confirmed.

The exploitation timeline is the detail defenders should carry away. Security Affairs reports that after finding an active Stripe API key, Ransomnews researchers accessed a merchant's customer list, created a fraudulent payment link and executed a $1 test charge within 17 hours. The key alone was sufficient. A live secret key unlocks customer and stored-payment-method enumeration, charge and payment-intent creation, refunds issued to attacker-controlled accounts, webhook endpoint modification to intercept future payment notifications, and in some configurations access to connected accounts where Stripe Connect is enabled. It is not a partial credential.

What Organizations Should Do

1. Rotate every live-mode Stripe secret key now, without waiting for confirmation of exposure. Given a 50,000-key exposed pool and an actor claiming 20,000 more in reserve, absence of evidence is not evidence of absence. Treat any sk_live key that has ever touched a repository, CI system, container image or developer workstation as burned.

2. Audit the Stripe dashboard for unauthorised webhook endpoints and payout destinations. Webhook modification is a quiet persistence technique that survives key rotation if the endpoint is left in place. Check payout bank details against your own records, not against what the dashboard currently displays.

3. Replace unrestricted secret keys with restricted keys scoped to the minimum resources each service needs. Only nine of the 659 credentials in this dump were restricted keys. That ratio is the finding. A restricted key that can read invoices but not create payouts converts a catastrophic leak into a manageable one.

4. Run secret scanning across the full history of every repository, not just the current HEAD. Deleting a key from the latest commit leaves it in the git objects. Extend the same scanning to CI/CD logs, GitHub Actions output, build artefacts, container layers and backup archives, all of which are named in this incident.

5. Instrument Stripe API access for anomaly detection. Alert on first-seen source IPs or ASNs, bulk customer-list enumeration, expansion-parameter queries at volume, new payment link creation and small test charges. The 17-hour research timeline means detection windows are measured in hours, not days.

6. Review Stripe Connect exposure specifically. Where Connect is enabled, a single compromised platform key can reach connected accounts, extending impact well beyond the directly breached merchant.

7. Prepare customer notification against the higher end of the reported figures. With records spanning January 2022 to June 2026, affected individuals may include long-dormant customers absent from current active-user lists.

Sources: Stripe Merchant Breach Exposes 650 Live API Keys and 688,000 Custom... | 50,000 Stripe Secrets Leaked in Public Code | Live Stripe keys for 659 merchants, published for free Ransomnews | Live Stripe API Keys for 659 Merchants Leaked With 35 GB of Custome... | Leaked Stripe keys expose merchant accounts > Cyber Insider | Hundreds of Leaked Stripe Merchant Keys Expose Payment and Payout C... | API keys from 659 Stripe merchants leaked, exposing 688K customer r... | Live API keys expose 688,363 Stripe customer records across 42 coun...