A data leak published on a cybercrime data-trading forum has exposed live Stripe API credentials for 659 merchant accounts, along with approximately 35 GB of customer- and payment-related data.
The exposure affects an estimated 688,363 customer records across merchants in 42 countries, but available evidence indicates that Stripe’s own infrastructure was not breached.
The dataset was posted on 18 August 2026 by a forum seller using the alias “Satanic” and made available for free download rather than sold.
Ransomnews reportedly reviewed the material offline and notified Stripe before publishing its findings.
Independent reporting has also described the campaign as a merchant-secret exposure rather than a compromise of Stripe’s platform.
The leak spans 17,654 files and includes data exported through Stripe API endpoints, including customers, charges, payment intents, Checkout sessions, invoices, payouts, balance transactions, refunds, disputes, subscriptions, products and prices.
The records in the dataset reportedly range from 4 January 2022 through 1 June 2026.
The forum listing misleadingly claimed that Stripe itself had been hacked. However, the reported evidence instead points to stolen or exposed credentials belonging to individual businesses that use Stripe for payment processing.
According to the dataset metadata, 573 accounts could accept payments, 531 could make payouts, and 519 could reportedly do both.
A Stripe secret key is a high-impact credential because it provides programmatic access to a merchant account.
Depending on enabled permissions and API version, an attacker could enumerate customer data, retrieve transaction records, create charges, issue refunds, alter payment workflows, or potentially modify payout destinations.
Security researchers have repeatedly warned that exposed keys in repositories, CI/CD logs configuration files can quickly lead to payment fraud and account misuse.
The largest share of impacted merchants was reportedly located in the United States, with 212 accounts, followed by the United Kingdom with 81, France with 57, Canada with 38, Brazil with 30 and Australia with 27.
Ransomnews said it did not use the exposed keys to authenticate to Stripe, access merchant systems or inspect individual customer records. Instead, it assessed the dataset’s internal structure.
The seller goes by Satanic, an established account on the forum with 779 posts and a reputation score approaching 2,000.
Ransomnews Researchers said that, the 659 credentials listed, 650 were reportedly live secret keys beginning with the sk_live prefix, while nine were restricted keys. The collector’s index marked every key as valid at the time of collection.
659 Stripe Merchant API Keys
The files reportedly contained Stripe object identifiers consistent with production API output, including customer IDs prefixed cus_, charge IDs prefixed ch_, payment-intent IDs prefixed pi_, account IDs prefixed acct_, and live Checkout session IDs beginning cs_live_.
Less common identifiers, including pmc_ for payment method configurations, il_ for invoice line items, du_ for disputes and seti_ for Setup Intents, were also reportedly present.
Notably, the dump does not appear to contain full payment card numbers. Card objects contained tokenized metadata such as brand, last four digits, expiration date, funding type, issuing country and payment fingerprint fields normally returned by Stripe’s API.
That reduces, but does not eliminate, the privacy and fraud risk to affected customers.
The dataset does not identify how the 659 credentials were obtained. Likely sources include infostealer logs harvested from developer devices, API keys committed to public repositories, exposed .env files, misconfigured cloud storage, container images, CI/CD logs and insecure backups.
This incident illustrates the operational difference between a public API key and a full-privilege secret. A key leaked from source code can be validated at scale, then used to export API-accessible data systematically.
Reporting on the wider issue has identified public code repositories, GitHub Actions logs and misconfigured web servers as common sources of exposed Stripe secrets.
Affected businesses may not yet know that their keys were exposed. Merchants should immediately rotate all live secret keys, examine Stripe Dashboard security and API activity logs, and review payout settings and linked bank-account details for unauthorized changes.
Organizations should also replace broad secret-key usage with narrowly scoped restricted keys wherever possible.
Secrets must remain server-side, never be embedded in frontend code, and should be removed from Git history, build logs, container layers and documentation.
Restricted keys help limit damage because permissions can be scoped to only the API operations an integration genuinely needs.
For security teams, the priority is credential discovery: scan repositories, CI/CD pipelines, environment files, cloud storage, endpoint telemetry and infostealer exposure feeds for Stripe credentials, then revoke and replace every exposed key.
[Live Webinar] Join Elastic & UnderDefense to learn how small security teams can unify AI visibility and agentic response into one operating model. -> Register Now
