.svg){kind=icon}
Recent reporting describes a dataset containing Stripe API credentials for hundreds of merchant accounts, together with customer and payment-related data apparently retrieved through those credentials.
According to the original Ransomnews investigation, the archive related to 659 merchant accounts and 688,363 customer records. Those figures have not been independently confirmed by Stripe, so this article treats them as reported rather than established facts.
The crucial distinction is that the reviewed sources do not show a breach of Stripe’s central systems. The reported exposure concerns merchant-controlled secret keys that may have escaped from websites, hosting environments, code repositories or development systems.
For a business accepting website payments, the practical question is therefore not simply “Do we use Stripe?” but “Where are our live credentials stored, who can access them, and what activity has occurred?”
Evidence status: what is reported and what remains unknown
Reported by the original investigator
Ransomnews says it analysed the archive offline and found 659 merchant accounts, 688,363 customer records, 650 live secret keys and nine restricted keys. It did not authenticate against Stripe or use the keys.
Confirmed through official guidance
Stripe’s documentation confirms that secret and restricted API keys are credentials, must remain private, and can expose customer data or permit unauthorised actions if obtained by another party.
Still unconfirmed
The complete route by which every credential was obtained, the number of affected businesses, whether all keys were still active when reported and the separate 50,000 total have not been independently verified. We found no public evidence that Stripe’s central infrastructure was breached.
What has reportedly happened?
On 18 August 2026, a dataset was published containing what researchers described as valid API credentials for 659 Stripe merchant accounts.
According to the original Ransomnews investigation, the archive contained approximately 35GB across 17,654 files and included 688,363 customer records. Researchers reported that 650 of the exposed credentials were live secret keys and nine were restricted keys.
The extracted Stripe information reportedly included:
- Customer records
- Charges and payment intents
- Checkout sessions
- Invoices and subscriptions
- Refunds and disputes
- Payout and balance information
- Partial card details such as the card brand, expiry date and last four digits.
Researchers found no full payment-card numbers in the archive. This is consistent with Stripe’s tokenised payment model, under which full card numbers are not returned through the ordinary Stripe API.
Ransomnews states figures of 659 merchants, approximately 35GB and 688,363 customer records. Other coverage has repeated slightly different totals. Until Stripe or affected merchants provide independent confirmation, the figures should remain explicitly attributed and provisional.
What does the “50,000 Stripe secrets” headline actually mean?
Security Affairs reports that more than 50,000 unique Stripe-related secrets were found across public repositories, GitHub Actions logs and misconfigured web servers.
At the time of this review, we could not actually identify a separately published primary dataset or methodology supporting that total. It should therefore be treated as a reported figure, and not a verified count of live keys or compromised businesses.
The separate 659-account dataset is more specific because Ransomnews says it examined the archive offline and checked whether its structure was consistent with Stripe API output. Ransomnews states that it did not authenticate against Stripe, use the keys or access merchant systems.
DarknetSearch’s analysis also distinguishes merchant credential exposure from a breach of Stripe’s infrastructure and identifies the acquisition method, active status of every key and complete number of affected organisations as unverified.
How could a Stripe key leak from a website?
A Stripe secret key is used by a website, ecommerce plugin or business application to authenticate itself when communicating with Stripe.
It is not normally shown to customers. Instead, it may be stored within:
- A website’s hosting configuration
- A WordPress or WooCommerce database
- An ecommerce, booking or subscription plugin
- A server environment file
- A CRM or automation platform
- A deployment system
- A developer’s computer
- A source-code repository or backup
Possible exposure routes include a configuration file accidentally becoming publicly downloadable, a secret being committed to GitHub, diagnostic logs printing the key, an exposed website backup, a compromised administrator account or malware stealing credentials from a developer’s computer.
The original dataset does not identify one confirmed method that explains all 659 merchants. Different businesses may have exposed their credentials in different ways.
Once a criminal has a valid secret key, they do not necessarily need the merchant’s Stripe password or multi-factor authentication code. The key allows software to authenticate directly to Stripe’s API.
Depending on its permissions and the account configuration, that may allow an attacker to read customer and transaction records, create payment requests, issue unauthorised refunds, alter webhook settings or access certain payout-related functions.
Does every business using Stripe need to worry?
Using Stripe does not automatically mean your account was compromised. Your exposure depends heavily on how payments are collected.
Stripe Payment Links or manually created invoices
If customers are sent to a Stripe-hosted Payment Link, your website may contain only the public payment URL. A secret API key does not normally need to be stored on the website, making this specific exposure route less likely.
Website, WooCommerce or booking-system checkout
If customers pay directly through a website, ecommerce plugin, booking system or subscription platform, a secret key or connection token probably exists somewhere within that integration.
That does not mean it has leaked, but its location and protection should be confirmed.
A visible publishable key is not automatically a breach
Stripe publishable keys commonly begin with pk_live_ and are intended for use within webpages and applications.
Secret keys beginning with sk_live_, and restricted keys beginning with rk_live_, must remain private. Businesses should not paste these keys into online breach-checking websites or send them by email for somebody to inspect.
What should businesses do now?
Businesses with a Stripe website integration should ask their website or IT provider to complete a focused review.
Recommended checks include:
- Identify every Stripe integration
Establish which websites, plugins, applications, CRMs and automation systems connect to the live Stripe account. - Review active live keys
In the Stripe Dashboard, review every live secret and restricted key. Confirm why it exists, where it is stored and which system uses it. - Inspect API activity
Use Stripe Workbench to look for unfamiliar IP addresses, unusual customer-record access, unexpected refunds, new payment links, webhook changes, transfers or payout-related activity. - Verify payouts and bank details
Confirm that every payout destination and external bank account belongs to the business. Investigate anything unfamiliar immediately. - Rotate exposed or uncertain keys
Stripe recommends rotating a key promptly when compromise is suspected. The replacement must be installed and tested before the old key is removed unless unauthorised activity requires immediate revocation. - Check the website and development trail
Search website configuration, databases, backups, code repositories and deployment logs for secret credentials. Removing a key from a current file does not remove copies from historical backups or repository history. - Reduce the permissions available
Where supported, replace broad secret keys with restricted keys that grant only the access required by that integration. Stripe also supports IP restrictions where the website or application uses predictable server addresses. - Protect the systems holding the key
Review hosting, WordPress, administrator and developer security. Apply updates, remove unused accounts, enable strong multi-factor authentication and investigate devices that may have been exposed to credential-stealing malware.
Stripe’s own guidance advises businesses to store secrets in protected systems, avoid repositories and messages, use restricted keys, audit request logs and rotate credentials where abnormal activity is suspected. See Stripe’s API-key security guidance and compromised-key response procedure.
What if suspicious activity is discovered?
Do not simply rotate the key and consider the incident closed.
Preserve the relevant Stripe logs, record when the incident was identified and establish what information was accessed. Check payments, refunds, webhook destinations, connected accounts, payout settings and the business bank account.
Contact Stripe Support through the authenticated Dashboard if there are unauthorised transactions, payout changes or connected accounts.
If customer information was accessed, the incident may constitute a personal data breach. UK organisations must assess the likely risk to individuals and keep a record of the incident. Where a breach is likely to create a risk to people’s rights and freedoms, the ICO says it should be reported without undue delay and, where feasible, within 72 hours of becoming aware of it. See the ICO’s personal data breach guidance.
How this article was prepared
This article was prepared by reviewing the original Ransomnews investigation, reporting from Security Affairs and DarknetSearch, Stripe’s current API-key guidance and the ICO’s breach-reporting guidance.
Incident figures are attributed to their source and remain provisional unless confirmed by Stripe or affected merchants. Operational recommendations are based primarily on Stripe and ICO guidance.
Sources and further reading
Information in this article reflects publicly available reporting as of 25 August 2026. Some incident figures and the original method by which every merchant credential was obtained have not been independently confirmed.
Jake Hall
Cyber Security and Infrastructure Analyst · Jake helps businesses stay secure and compliant through managed IT security support and guidance towards Cyber Essentials certification.