A dataset published on a data-trading forum on 18 August 2026 contains live Stripe API keys for 659 merchant accounts, along with roughly 35 GB of customer and payment data pulled from them. Ransomnews analysed the files offline and reported the exposure to Stripe before publishing. Stripe itself was not compromised. The keys belong to merchants.
What was published
The listing went up in the early hours of 18 August under a headline claiming a breach of Stripe itself. That framing is wrong, and it matters, so it is worth dealing with first. Nothing in the dataset indicates any failure of Stripe’s own systems. What the files show is 659 merchants whose secret API keys ended up in someone else’s hands, after which that person used the keys the way any developer would, and pulled down everything the API would return.
The seller goes by Satanic, an established account on the forum with 779 posts and a reputation score approaching 2,000. That is not a throwaway identity. The data was posted for free download rather than sale.
Each merchant gets a folder. Inside it sit up to 27 different Stripe resource types: customers, charges, payment intents, checkout sessions, invoices, payouts, balance transactions, refunds, disputes, subscriptions, products, prices and more. Several folders also carry customers_expanded and charges_expanded variants, which is what you get when you call the API with expansion parameters. Whoever did this was thorough.
The keys are the story
Every folder also holds a small file that is not a Stripe object at all. It’s the collector’s own index, and it records the key that was used, a hash of that key, the account identifier it belongs to, and whether the account could take payments and make payouts at the time.
650 of the 659 keys are live secret keys. Nine are restricted keys. All 659 are marked valid, meaning the collector tested each one and it worked.
A Stripe secret key is not a password to a dashboard. It is full programmatic access to the account. Anyone holding one can read every customer record, create charges, issue refunds, and change where payouts are sent. The 519 accounts in that bottom row could, on the collector’s own record, both take money in and move it out.
Whether those keys still work today depends entirely on whether anybody has rotated them, and there is no sign in the data that the merchants knew.
How we know the data is real
We checked the structure rather than the contents, because structure is harder to fake and because reading 688,000 people’s payment records is not something a publication should do.
Stripe gives every object a prefixed identifier, and the dataset uses eighteen of them correctly. The obvious ones are easy enough to guess: cus_ for customers, ch_ for charges, pi_ for payment intents. The ones that convinced us are the obscure ones. pmc_ is a payment method configuration. il_ is an invoice line item. du_ is a dispute, seti_ a setup intent, req_ a request identifier. Nobody assembling a fake gets that tail right.
Checkout sessions carry the cs_live_ prefix, which distinguishes production from Stripe’s test mode. Account identifiers follow the acct_ format. Card objects contain exactly the fields the API returns when it hands back a saved card: last four digits, brand, expiry month and year, fingerprint, funding type and issuing country. Those seven appear together, in equal numbers, every time.
We also went looking for card numbers, and there aren’t any. Every long numeric string we found and tested turned out to be a network_transaction_id, which is a real and fairly obscure Stripe field. That is what you would expect. Stripe does not return primary account numbers through its API, so a genuine harvest can’t contain them, and a fabricated one probably would.
Where the keys came from
The dataset doesn’t say, and we are not going to guess at a single source for 659 separate merchants. The realistic candidates are the ordinary ones: secret keys sitting in infostealer logs lifted from developer machines, keys committed to public repositories, keys left in exposed environment files, keys pulled out of misconfigured backups. Stripe’s own documentation says the company scans for exactly this, and describes finding merchant keys on repositories and package registries.
What the collector added was patience. Gathering keys is common. Validating several hundred of them, then systematically walking the API for each account and archiving the results into a consistent folder structure, is a different level of effort.
What we are not publishing
There is a great deal in this dataset that we are not publishing, and that is deliberate.
No merchant names. No domains. No account identifiers, no key hashes, no key material, and nothing that would narrow the field for somebody trying to work out which businesses are affected. The keys may still be live. Naming the merchants while that is true would be handing over a target list, and the people who would suffer are 688,000 customers who have no idea any of this happened.
We contacted Stripe before publishing and set out what we found. We asked whether the keys were already known and revoked, whether affected merchants would be notified, and on what timeline. This article will be updated with their response.
What merchants should do
Rotate your Stripe secret keys. Not because you appear in this dataset, since we are not saying who does, but because rotation costs an afternoon and the alternative is finding out the hard way.
- Roll every live secret key in the Stripe Dashboard, then check your security history for API activity you cannot account for.
- Move integrations onto restricted keys with the narrowest scope that works. A read-only key that leaks is a bad day. A secret key that leaks is a very different one.
- Use access policies to limit which IP addresses can use a key at all, which turns a stolen key into a much less useful object.
- Check payout settings and bank details, since that is the fastest route from stolen key to stolen money.
- Search your own repositories, container images, CI logs and environment files for keys. Most exposures start at home.
For anyone tracking the wider pattern, this is the same shape as most of what we cover: no exotic technique, no vulnerability, just credentials that escaped and an operator patient enough to use them at scale. Our work on initial access brokers covers the market those credentials usually pass through, and you can check whether your own accounts appear in circulating stealer logs on Stealercheck.
Sources
- Stripe, Security at Stripe
- Stripe, Protecting against compromised API keys
- Stripe, API keys, restricted keys and access policies
The Ransomnews Monthly
One email a month. Original leak-site data, victim census updates, and the findings that did not make the articles. No spam, unsubscribe any time.
Double opt-in. We store your email, signup time, and IP for consent records (GDPR Art. 7). See our privacy policy.