How do I know if my Stripe keys were in this specific leak?

You may not get a definitive individual notification quickly, since the dataset was posted to a cybercrime forum rather than disclosed by Stripe directly to every affected merchant. Treat 'were we in the list' as secondary to 'could this happen to us' — the mechanism (a live secret key sitting in a public repo, CI log, or exposed .env file) is what to rule out regardless of whether your specific account appears in this dataset.

What's the actual damage a leaked live secret key allows?

Reported analysis of the sampled keys found several were still active and usable to list customer records, create payment links, modify configured webhooks, and process test charges — meaning a live sk_live key gives an attacker a working integration into your Stripe account, not just read access to old data.

Is rotating the key enough, or do we need to do more?

Rotation stops the specific leaked key from working, but it doesn't tell you why it was exposed in the first place. If the root cause was a public repo or an exposed CI log, a new key dropped into the same insecure location leaks again on the same schedule. Fix the exposure path — secret-scanning on repos, redacted CI output, scoped-down key permissions — not just the individual credential.

Does this affect us if we use a payment processor other than Stripe?

The specific dataset is Stripe-scoped, but the mechanism isn't Stripe-specific — any payment processor's live API keys sitting in a public repo, CI/CD log, or exposed environment file are exposed the same way. If you process payments through Adyen, Braintree, or another provider, the same 24-hour checklist below applies with that provider's key format and dashboard in place of Stripe's.

Leaked Stripe keys: what to check in 24 hours

Q: Was Stripe itself hacked?

No. Every outlet that has analyzed the leaked dataset agrees the exposure sits on the merchant side, not Stripe's platform — live secret keys were pulled from individual businesses' own public code repositories, unmasked CI/CD logs, misconfigured servers, and exposed environment files, then used to call Stripe's API exactly as a legitimate integration would. Stripe's infrastructure was not the point of failure.

The short answer

On 2026-08-18, a forum seller published live Stripe secret API keys for 659 merchant accounts alongside roughly 35 GB of pulled customer and transaction data — an estimated 688,000 records across 42 countries. This was not a breach of Stripe's own platform: every independent analysis of the dataset points to the keys being harvested from the merchants' own public code repositories, unmasked CI/CD logs, misconfigured servers, or exposed environment files, then used to call Stripe's API the same way a legitimate integration would. If your business takes payments through Stripe — and a meaningful share of casino, crypto-exchange, and fintech operators do, alongside their primary licensed payment rails — the question worth answering in the next 24 hours isn't "were we in this specific dataset," it's "could our own secret keys leak the same way."

Who this is for

This is written for whoever owns application or infrastructure security at a company processing payments through Stripe — a CISO, Head of Engineering, or the on-call engineer who gets asked "are we affected" every time a payment-platform incident makes the news. It matters most for casino, sportsbook, and crypto-exchange operators specifically, because Stripe or a Stripe-like processor commonly sits alongside a primary gaming or custody-focused payment rail for subscriptions, merchandising, or ancillary services — meaning the account can hold real customer PII and transaction history even when it isn't the operator's primary cashier flow, and a review of "do we have live secret keys" often isn't part of routine security scope because that ancillary Stripe integration was never flagged as a security-relevant asset.

What we know

What was published: a dataset posted 2026-08-18 by a forum actor using the alias "Satanic," containing what's reported as 659 merchants' Stripe API credentials (650 live secret keys with the sk_live prefix, nine restricted keys) plus roughly 35 GB of pulled customer and payment data covering an estimated 688,000 records across 42 countries.
Root cause, as independently reported: multiple security-research outlets that examined the dataset (not Stripe itself) describe the credentials as harvested from merchants' own exposed surfaces — public GitHub repositories, unmasked GitHub Actions logs, misconfigured web servers, and exposed .env files or debug logs — not from any vulnerability in Stripe's platform.
Confirmed capability: analysts who tested sampled keys reported several were still live and could list customer data, create payment links, modify configured webhooks, and process test charges — a working API session, not a stale credential.
Stripe's response, as reported: after disclosure, Stripe worked to identify affected merchants and rotate or revoke compromised keys; most of the keys in the leaked dataset are now reported as revoked or rotated. We haven't found a direct first-party Stripe statement independent of this third-party reporting, so treat the response details as widely reported rather than vendor-confirmed.
What this is not: there's no CVE here, no exploit against Stripe's infrastructure, and nothing to patch on Stripe's side. It's a credential-hygiene failure on the merchant side of the integration — the same failure mode that exposes AWS keys, database credentials, or any other secret dropped into a public repo or an unredacted log.

We're not naming or speculating about which specific merchants were affected — that's not verified information we can add value to, and it isn't what determines your own exposure.

What to check in the next 24 hours

Step	Action	Why it matters
1. Repo scan	Run a secret-scanning pass (`gitleaks`, `trufflehog`, or GitHub's own secret scanning) across every repository — including private ones and full commit history, not just the current branch tip	A key removed from the latest commit is still exposed if it's reachable in history; public-repo exposure is the reported root cause here
2. CI/CD log audit	Check whether your CI/CD pipeline (GitHub Actions, GitLab CI, CircleCI, Jenkins) prints environment variables or secrets to build logs, and whether those logs are publicly readable	Unmasked CI logs are one of the specifically reported exposure paths in this incident
3. Environment file check	Confirm `.env` files and equivalent config aren't committed to any repo, aren't in a publicly readable storage bucket, and aren't left on a server behind default or no authentication	Same category of exposure as the CI-log path — a debug or backup copy of a config file is a common miss
4. Key inventory	List every live Stripe key (and any other payment-processor key) currently in use, where each one lives, and who created it	You can't rotate or scope what you haven't inventoried; this is the same asset-inventory gap that shows up in most exposed-credential incidents
5. Least-privilege rescope	Replace any broad-scope `sk_live` key with a restricted key limited to the specific API operations your integration actually needs	A restricted key limits blast radius even if it does leak later — this incident specifically noted most exposed keys were unrestricted live secret keys
6. Dashboard review	Check your Stripe (or other processor) dashboard for API request logs, webhook endpoint changes, and payment-link creation you don't recognize	The confirmed-live keys in this leak were used to list data and create payment links; the same activity pattern is what to look for in your own logs
7. Rotate on suspicion	If any of the above turns up a key that's ever been in a public repo, an unmasked log, or an exposed file — rotate it now, don't wait for confirmation you were part of this specific dataset	Rotation is cheap; leaving a possibly-exposed live key in place while you investigate is not

If step 6 turns up activity you can't explain — payment links you didn't create, webhook endpoints pointed somewhere unfamiliar — stop treating this as a hygiene review and escalate to an incident response engagement.

Why this matters specifically for casino, crypto, and fintech operators

Payment-key exposure lands harder in these sectors for a structural reason: a casino, sportsbook, or crypto exchange usually runs more than one payment integration side by side — a primary cashier or custody rail built for the regulated core product, plus a Stripe-style integration for subscriptions, merchandising, affiliate payouts, or B2B billing that was set up by a growth or product team, not security. That second integration is exactly the kind of asset that gets missed in security reviews scoped narrowly around the primary cashier or wallet infrastructure — the same "not labeled a security-critical system, so it's out of scope" pattern we've written about before in an unauthenticated SQL injection in Metabase, where an internal BI tool nobody thought to scope held direct database credentials.

A vulnerability assessment that treats "every system with a live API credential" as in-scope — not just the systems a security team already knows about — is what catches an exposed Stripe key in a public repo or an unmasked CI log before it turns into someone else's forum post. Our own VA engagements combine automated scanning across external and internal surfaces with manual validation specifically so a secondary payment integration doesn't get waved through as "not the primary cashier, not in scope."

Limitations

This checklist gets you to "no live keys currently sitting in an exposed location that we know of" — it doesn't prove your broader environment has no other exposed secrets, and it doesn't replace ongoing monitoring for the next one. A vulnerability assessment finds this kind of exposure proactively across your estate at a point in time; it doesn't watch continuously, which is what a Managed SOC is for. And if the dashboard review turns up confirmed unauthorized activity, rotating the key doesn't undo whatever already happened with it — that's an incident-response question, not a hygiene one.

What to do next

Run the repo and CI-log scan today regardless of whether you think you're affected — the mechanism here (a live payment-processor key sitting in a public or unmasked location) is common enough that "we don't use Stripe as our primary rail" doesn't rule it out for a secondary integration. Once the immediate checklist is done, the durable fix is treating every system with a live payment-API credential as security-relevant by default, not by exception. Tell us what payment integrations you run and we'll scope a vulnerability assessment that covers the secondary systems a narrower review tends to skip.

Sources and review

Incident details (dataset size, merchant count, record count, key composition, reported root cause, and Stripe's reported remediation response) are drawn from independent security-research reporting — GBHackers, Cybersecurity News, HackRead, Security Affairs, InfoStealers, and CybersecAsia all published consistent analysis of the same dataset. We have not found a direct first-party statement from Stripe independent of this reporting; the root-cause and remediation details above are presented as widely and consistently reported, not vendor-confirmed. VA methodology and engagement details are AnySec's own published service terms. No exploitation technique is described beyond what's already public in the cited reporting. Author: AnySec Engineering. Published 2026-08-21; last reviewed 2026-08-21.