Stripe Vendor Leak Exposes 1,033 Live Merchant API Keys

Read the headlines and you would think Stripe got hacked. It did not. Every key in that archive came out of a merchant's own infrastructure, and every record in it was pulled through Stripe's legitimate API by someone holding a credential that a developer left somewhere public. That distinction is the whole story, because it means the fix is not Stripe's to ship. It belongs to the 659 or so businesses whose secret keys are now a free download.

Key Takeaways

• An actor using the alias "Satanic" published the archive free on pwnforums on 18 August 2026 and told Hudson Rock researchers, minutes after the drop, that it represented a fraction of roughly 20,000 Stripe keys they claim to hold.
• Hudson Rock counted 669 vendor folders and 1,033 compromised API keys at 33 GB; CybersecAsia reports 659 merchant accounts, 650 live sk_live keys and 35 GB, so the exact tally depends on how duplicates and folders are counted.
• CybersecAsia counts 688,363 customer records spanning January 2022 to June 2026, drawn from merchants in 42 countries, with the United States (212 accounts), the United Kingdom (81) and France (57) most represented.
• CybersecAsia found 519 of the exposed accounts could both accept payments and issue payouts, meaning a stolen key was enough to move money outward, not merely read data.
• Stripe's infrastructure was not breached and Stripe has not publicly commented; Hudson Rock traces the keys to exposed environment files rather than an infostealer campaign, and GitGuardian counted 28.65 million new hardcoded secrets on public GitHub during 2025 alone.

Was Stripe Itself Breached?

No. Stripe's platform was not compromised, and no researcher covering this incident claims otherwise. Hudson Rock's writeup, Analyzing Stripe Vendors Breach: Confirmed Vendor Exposure and Claims of 20,000 Compromised APIs, is careful about this: the exposure sits with the vendors, not the processor. The data was exported through documented Stripe API endpoints by someone who had a valid key, which is exactly what a valid key is for.

That is a duller headline and a worse problem. A breach at Stripe would have one owner, one incident response team and one disclosure. This has hundreds of owners, most with no security team, many of whom still do not know their key is in the file. Cybernews reported it as an alleged Stripe breach, and that framing is why the correction matters: a merchant who reads "Stripe was hacked" concludes there is nothing to do.

Stripe itself has not publicly commented. We found no statement, status page entry or press response from the company on this archive, and every account of the incident rests on independent analysis rather than a disclosure by the processor. Worth stating plainly, because "Stripe was not breached" is a researcher conclusion, not a company denial.

Why Do the Numbers Not Match Across Reports?

Because researchers counted different things from the same archive, and nobody is wrong. Hudson Rock reports 669 vendor folders, 1,033 API keys and 33 GB advertised, while noting the actual downloaded file was 2.37 GB compressed. CybersecAsia's analysis gives 659 merchant accounts, 650 live sk_live keys, 17,654 files and 35 GB uncompressed.

Read them side by side and the gap resolves. A folder is not an account: some merchants appear twice, some keys are test or restricted keys, and 1,033 keys across roughly 660 accounts means the average victim leaked more than one credential. That is the number worth sitting with. If your organisation lost a Stripe key, the base rate says you probably lost a second one elsewhere.

What Can Someone Do With a Live Stripe Secret Key?

Everything the merchant can do, minus the dashboard login. Stripe's own best practices for managing secret API keys states it plainly: "If an unauthorized party obtains your secret API key, they can make unauthorized charges, access customer data, or disrupt your integration." A key prefixed sk_live is a bearer credential with no second factor attached to it. Stripe's API keys reference describes the secret key type as carrying "unrestricted permissions to all Stripe APIs" and adds that "because you can't limit these permissions, we don't recommend secret keys for new use cases."

Concretely, a holder of a live secret key can list every customer object and page through names, email addresses, phone numbers, billing addresses and the last four digits of cards. They can enumerate charges, invoices, payment intents, subscriptions and disputes. They can create charges. They can issue refunds to a destination they control. On the 519 accounts that had payout capability, they can inspect and in some configurations redirect where money lands.

Compare the two safer key types. A publishable key, prefixed pk_live, is built to sit in a webpage and can only do what is already public. A restricted key, prefixed rk_live, carries a scoped permission set, so a monitoring vendor gets read only access to disputes and nothing else. Stripe recommends restricted keys precisely to cap the blast radius of a leak. That most keys here were unrestricted is why the archive runs to 35 GB.

How Did 1,033 Keys Get Out?

They were never stolen in a single event. They accumulated. Hudson Rock found no infostealer infections tied to the specific vendor domains in this dataset and points instead at publicly exposed environment variables and shared infrastructure. The scale of that standing crop is measured annually: GitGuardian's State of Secrets Sprawl 2026 recorded 28.65 million new hardcoded secrets on public GitHub during 2025, a 34 percent rise year over year, and found that credentials confirmed valid in 2022 were still valid at a rate above 64 percent when retested in January 2026. Leaked keys do not expire on their own.

The sources are the same four every time. Keys hardcoded into a repository that later went public. GitHub Actions logs printing an unmasked environment variable. Misconfigured servers handing a .env file to anyone who asks. And infostealer logs from developer laptops. On the first and third of those, Security Affairs reports more than 50,000 unique Stripe secrets in public code and says over 3,000 exposed servers revealed Stripe related strings, roughly 12 percent of them a working key. Treat those two figures as second hand: Security Affairs attributes them to an analysis by Ransomnews, and no research firm has published the underlying method.

This is the second live credential dump we have written up this month. Five days before this archive was analysed, we covered 9,300 leaked AWS keys that still worked, 526 of them root — same root cause, different provider. The pattern is not a Stripe problem or an AWS problem. It is that a secret key is a password nobody rotates, nobody monitors, and nobody notices leaving, because unlike a stolen user password it never triggers a failed sign in alert.

What Should Developers and Merchants Do Right Now?

Assume exposure and rotate, because Stripe's guidance is that any exposed key should be treated as compromised even without evidence of use. In order:

• Roll every live secret key today. Stripe's guide to rotating an API key documents a grace period in which the old and new key both work for up to 7 days, so there is no downtime excuse. Do it even if you are confident, because confidence is what put 650 keys in this archive.
• Grep your history, not just your working tree. Search the full git history, CI configuration and build logs for the strings sk_live and rk_live. A key deleted in a later commit is still in the history and still readable by anyone who clones the repository.
• Replace broad secrets with restricted keys. Stripe's restricted API keys guide covers migrating off unrestricted secret keys. Every integration that only reads should hold a read only key, and every third party vendor you hand a credential to should get one scoped to the resource it needs.
• Read the API request logs. Stripe records every call made with every key and surfaces them in Workbench request logs. Look for unfamiliar IP addresses, bulk listing of customer objects, and any refund or payout you cannot match to a human decision. Then confirm your payout bank details have not changed.
• Turn on secret scanning, a pre commit hook and an access policy. Stripe recommends rejecting commits matching the key patterns before they reach a remote, and its access policies can bind a live key to specific IP ranges, ASNs or countries and block Tor exit nodes, anonymous VPNs and residential proxies outright. Stripe advises setting a policy on every live key.
• Verify webhook signatures. A leaked key is often paired with an endpoint that trusts anything posted to it. Checking the Stripe signature header stops a forged event from marking an order as paid.

Customers rather than merchants have narrower options, and it is worth saying so. You cannot rotate someone else's key. You can treat any card used with a small online merchant since 2022 as potentially enumerated, watch for small test charges, and read our note on how infostealer databases recycle credentials before reusing a password.

What This Means for Your Inbox

The payment angle gets the headlines, but the contact data is what reaches you. Every customer object in those 688,363 records carries an email address, usually a name, often a phone number and a billing address, and always a purchase history: what you bought, when, for how much, and the last four digits of the card you used. That is 688,363 people, roughly the population of Denver, handed a package of details that no legitimate sender would know unless they had processed your order.

A phishing message built on that data does not look like phishing. It cites a real invoice number, a real amount, a real date and the correct card digits, and asks you to update a payment method for a subscription you genuinely hold. The business emails in the archive are the other half: they identify the merchant staff who send order confirmations, which is exactly who an attacker impersonates. We saw the same shape in the Suno breach that exposed 55 million email addresses alongside Stripe records earlier this year.

No extension fixes this one, and we will not pretend otherwise. The defence is behavioural: never act on a payment request that arrived by email. Open the merchant's site yourself and check the subscription from inside your own account. Treat unusually accurate detail as a warning sign rather than reassurance, because accuracy is now cheap.

Sources: Hudson Rock: Analyzing Stripe Vendors Breach; Cybernews: Fintech giant Stripe faces alleged data breach; Security Affairs: 50,000 Stripe secrets leaked in public code; CybersecAsia: Live API keys expose 688,363 Stripe customer records across 42 countries; Stripe: Best practices for managing secret API keys; Stripe: API keys; Stripe: Restricted API keys; GitGuardian: The State of Secrets Sprawl 2026. Stripe has not publicly commented on this archive. Figures reported between 18 and 27 August 2026 and subject to revision; the actor's claim of 20,000 keys is unverified.