Leaked Stripe keys exposed data of over 688,000 customers in 42 countries

20.08.2026 | International news

An archive containing active API keys for 659 Stripe merchant accounts holds customer and payment data. The evidence points to compromised merchant keys, not a breach of Stripe itself.

Снимка от HaeB, Wikimedia Commons (CC BY-SA 4.0)

A published archive of API keys belonging to merchants using Stripe has exposed data related to approximately 688,363 customers across 42 countries. The incident became public on August 18, when a user with the pseudonym "Satanic" uploaded the information for free on a data trading forum.

The initial claim that Stripe itself had been breached is not supported by an independent analysis of the available data. It appears that these are compromised secret keys of individual merchants, which were used to extract data through legitimate requests to the Stripe API.

What is the scope of the leaked data

The published archive is approximately 35 GB in size and contains 17,654 files. It includes records of customers, payments, payment intents, payment sessions, invoices, subscriptions, refunds, disputes, transfers, and balance transactions.

The data covers the period from January 2022 to June 2026. According to the analysis, the set contains keys for 659 merchant accounts. Of these, 650 are active secret keys with the "sk_live" prefix, and nine are restricted API keys.

A total of 519 of the affected accounts had the ability to both accept payments and perform payouts. This creates a risk not only for the personal and payment data of customers but also for direct financial losses for the merchants.

The highest number of affected merchant accounts was reported in the US – 212. This is followed by the UK with 81 and France with 57 accounts.

How the keys were likely obtained

The "Ransomnews" investigation team analyzed the data offline and notified Stripe before publishing the material. According to their findings, the attacker obtained the merchants' secret keys and then used standard API requests to extract the information from the respective accounts.

Possible sources of the compromised keys include public code repositories, unprotected ".env" files, logs from continuous integration and delivery systems, improperly configured backups, diagnostic logs, and info-stealing malware on developers' devices.

The researchers found no evidence of a general info-stealer campaign against specific vendors. This allows for another possibility – automated scanning by bots for publicly accessible servers, files, and environment variables where secret keys were mistakenly left.

How serious is the risk

Analysts demonstrated that an active key can grant broad access to a merchant profile. Upon testing a working key, they were able to retrieve a customer list, create a fraudulent payment link, and conduct a test payment within 17 hours.

This means that a leaked secret key can be used to steal customer data, generate fake payment links, attempt unauthorized refunds, change notification settings, or divert funds when the account permissions allow it.

Hudson Rock reported a related post by the same perpetrator, who claims to possess about 20,000 compromised Stripe API keys and plans to release additional batches. This claim has not been independently verified.

What merchants should do

Organizations using Stripe must immediately rotate all active secret API keys and revoke the old ones, rather than simply generating new ones. It is necessary to review API activity logs, webhook notification settings, bank details for payouts, and any unusual payments, refunds, or transfers.

It is recommended to replace broad secret keys with restricted keys that provide access only to necessary functions. Keys should not be stored directly in source code, public repositories, logs, or files accessible over the internet.

Stripe offers automatic scanning for exposed secrets through a partnership program with GitHub. However, analysts point out that such tools do not cover all risk areas – especially logs from automated processes and misconfigured servers. Therefore, protection requires simultaneous access restriction, regular key rotation, and constant monitoring of development and deployment environments.