659 Merchants Leaked Their Own Stripe Keys. 688,000 Customers Paid For It.

Stripe didn't get breached. Its customers breached themselves, and then Stripe's own API did exactly what it was built to do: hand over the data to whoever held the key.

On August 18, 2026, a forum user going by Satanic posted a free archive on a cybercrime data-trading forum containing live Stripe secret API keys for 659 merchant accounts. Attached to those keys: roughly 35 GB of customer and payment data, an estimated 688,363 records spanning 42 countries, according to reporting from Ransomnews, Cyber Security News, and Cyber Insider. The listing falsely claimed Stripe itself had been hacked. It hadn't.

Ransomnews, which reviewed the material offline and notified Stripe before publishing, found something more mundane and more damning. The keys were harvested from the merchants' own environments, then used to call Stripe's API the same way any legitimate integration would. No exploit. No zero-day. Just unlocked doors that businesses left open.

Of the 659 credentials, 650 were live secret keys carrying the sk_live prefix, the real production keys capable of moving real money, according to Ransomnews and corroborating analysis from Cyber Security News and gbhackers. Nine were restricted keys. The dataset's own metadata marked all 659 as valid at the time of collection, meaning the collector actually tested them against Stripe's live systems.

The numbers get worse the further in you look. Of the affected accounts, 573 could accept payments, 531 could initiate payouts, and 519 could do both, according to Ransomnews' analysis of the collector's own index files. An attacker holding one of those 519 keys isn't just looking at customer data. They can pull money in and push it back out, redirect where payouts land, issue refunds, and read full transaction histories.

How merchants let this happen

The exposure routes are familiar to anyone who has worked in application security: API keys hardcoded into application code and pushed to public GitHub repositories, secrets left sitting in unmasked CI/CD logs, credentials harvested by infostealer malware running on developer machines, and misconfigured servers with broken access controls, according to Crypto Briefing and cyberpress. None of this required breaking into Stripe. It required someone forgetting to scrub a config file.

This is not an isolated incident. Investigations cited by Crypto Briefing found more than 50,000 Stripe API keys exposed in public domains, including GitHub Actions logs, suggesting the 659-merchant dump is a slice of a much larger ongoing problem, not a one-time event. Satanic reportedly claimed to be holding roughly 20,000 additional keys not included in this release, according to Crypto Briefing, though that claim is unverified.

The data itself, according to Ransomnews' structural review, spans 17,654 files organized into per-merchant folders covering up to 27 Stripe resource types: customers, charges, payment intents, checkout sessions, invoices, payouts, balance transactions, disputes, subscriptions, products, and pricing. Records are dated from January 2022 through June 2026. gbhackers reported the largest concentration of affected merchants sits in the United States (212 accounts), followed by the United Kingdom (81), France (57), Canada (38), Brazil (30), and Australia (27).

The dataset reportedly does not contain raw card numbers, according to cyberpress. Payment card data in Stripe's system is tokenized, exposing only last-four digits, card brand, expiry, and issuing country. That limits the risk of direct card-present fraud but does not limit the risk of phishing, business email compromise, refund fraud, or targeted social engineering built on real names, emails, and transaction histories, which cyberpress and Cyber Security News both flagged as the more likely follow-on threats.

Where responsibility actually lands

Stripe's terms of service put the burden of securing API keys on the merchants who generate them, and the company provides key rotation tools and scoped, restricted-key options specifically to prevent this scenario, according to Crypto Briefing. Cyber Insider's reporting frames this correctly as a machine-identity and secrets-management failure, not a payment-platform exploit. A provider can lock down its own infrastructure while its customers still leak credentials that carry the same authority as a password, minus the login screen. Nobody in this sourcing pool disputes that framing, and Stripe's own security guidance, cited by Cyber Insider, says the same thing: possession of a secret key lets an unauthorized party impersonate the merchant account outright.

The forum seller's decision to give the data away for free, rather than sell it, deserves attention. Ransomnews noted Satanic runs an established account with 779 forum posts and a reputation score near 2,000, not a throwaway identity trying to cash out fast. A free release maximizes reach and reputational damage rather than profit, which raises the odds this data ends up recirculated, scraped, and reused by lower-tier scammers for months.

None of the 659 affected merchants have been named publicly. Cyber Security News reported that researchers deliberately withheld merchant names, domains, account identifiers, and key material to avoid creating a roadmap for further abuse. That means any business running Stripe integrations, especially secondary ones bolted on for subscriptions or merchandising rather than the primary payment rail, has no way to confirm from this reporting alone whether it was hit. The only real move available to any Stripe merchant right now: rotate every live secret key, audit API logs for unfamiliar activity, verify payout bank details haven't changed, and stop assuming that because nobody named you, you're clean.