1,033 Stripe Secret Keys Leaked: Why Your .env File Is Now Part of Your Payment Security

A payment integration you trust with every checkout just became the target — not because Stripe was hacked, but because the keys that control it were left where anyone can scan for them.

On August 18, 2026, a threat actor known as Satanic published a dump on the illicit forum pwnforums containing 1,033 live Stripe secret keys (sk_live_...) belonging to 669 distinct vendors, plus customer and transaction records totaling 33 GB claimed (2.37 GB released in the first archive). In a direct exchange with Hudson Rock researchers minutes after the release, the actor claimed the initial dump was only a fraction of what they hold — approximately 20,000 Stripe APIs in total, to be released in subsequent batches.

This is not a vulnerability in Stripe. It is a secrets-exposure crisis at the vendors that use Stripe — and it is exactly the kind of incident that should prompt any store, SaaS, or marketplace using Stripe to check one file this week: your .env.

Here is what happened, what a sk_live key actually lets an attacker do, and the practical 5-step check that closes the risk without an enterprise secrets-management project.

What actually happened

Hudson Rock's analysis of the leaked data — published via its Infostealers research site — lays out the scope in detail:

A detail worth noting: while the actor advertises 669 database folders, many vendors registered their Stripe accounts with personal addresses — when accounts tagged as generic providers are excluded, Hudson Rock counts 323 uniquely identifiable business domains impacted. That does not overturn the 669 figure, but it helps readers gauge the business-vs-personal mix in the dump.

Two facts stand out for small businesses:

1. The leaked keys were live and had charge capabilities. Hudson Rock's screenshots show JSON with "sk_live_..." and explicit charge-access flags — meaning they are not test-mode keys or revoked placeholders. They are the same keys your backend uses to create charges, refunds, and payouts.

2. There is no single vulnerable plugin. The affected vendors run completely different stacks. Hudson Rock's telemetry found no infostealer infections tied to the specific vendor domains and no common WordPress plugin or framework. That points away from a supply-chain package bug and toward a systemic vector.

What a Stripe secret key actually controls

A Stripe secret key is not a read-only analytics token. Depending on its permissions, sk_live_... can be used programmatically to:

• View sensitive customer data (names, emails, phones, addresses, IP at time of purchase, purchase history)
• Access hosted invoices — including the last four digits of the customer's card
• Create charges, issue refunds, and alter account settings
• Potentially reroute payouts if account settings are changed
• Expose internal business logic, including active promotional codes (Hudson Rock found spreadsheets of promo codes with discount amounts and durations — mass abuse would drain inventory and revenue before a vendor notices)

For a store owner, that means an exposed key is not a "theoretical" credential leak. It is direct financial and operational control over your payment account — an attacker with the key can act through normal Stripe API calls with no exploit needed.

Why this is an .env and secrets problem, not a Stripe problem

Hudson Rock's current hypothesis is that the actor is running automated bots that mass-scan the web for misconfigured, publicly exposed .env files or debug logs that leak plaintext sk_live_ keys — or that a shared piece of infrastructure (cloud host, deployment tool) used by many vendors was compromised.

Both explanations explain the diversity of victims and the absence of localized malware. And both explain why the actor can credibly threaten 20,000 keys: .env exposure is an old, well-automated finding.

In a normally configured web server, https://yourstore.com/.env should return 403 or 404. When a deployment leaves .env readable — because the document root is misconfigured, a Docker image copies it, or a debug page dumps environment variables — the file that holds STRIPE_SECRET_KEY=sk_live_51H..., database URLs, and other SaaS tokens becomes a public URL that scanners find within days.

This is the same pattern behind last month's n8n disclosure (GitGuardian found 4,576 unique n8n API tokens in public GitHub commits, 321 still valid, each one a skeleton key to every workflow wired into that instance) — but the Stripe case is broader because the victims are not one platform's users. They are any business that happens to expose that file.

Who is affected — and who should still act

Directly affected: The 669 vendors in the initial dump (and potentially thousands more if the 20,000 claim proves accurate). If you use Stripe, assume you could be in a future batch — Hudson Rock has warned that the staggered-release pattern makes verification difficult until each batch appears.

Indirectly affected — and the reason to act now: Any business that uses Stripe and has ever had a .env file, debug log, or error page that prints environment variables reachable from the public web. You do not need to be in the initial 669 to be exposed by the same scanning technique.

If your store uses Stripe, WooCommerce Stripe, Shopify custom apps that proxy to Stripe, or a headless checkout that stores sk_live server-side, this is your prompt to verify the file is not public and the key has the least privilege it needs.

Why this matters even if you don't recognize the vendor names

Three reasons this deserves attention beyond the breach headline:

1. Your Stripe key is your bank key. Unlike a social-login token or an analytics key, a compromised secret key lets an attacker move money — refunds to attacker-controlled cards, or altered payout accounts. The financial impact is immediate, not theoretical.

2. Customer trust is part of the blast radius. The leaked data includes customer PII and purchase history tied to real Stripe invoices. Even if the money is recovered, the notification duty and reputational cost fall on the vendor — and "our .env was public" is not a credible explanation to customers or payment partners.

3. Promo-code and invoice data has resale value. Attackers do not need to empty your Stripe balance to profit. Harvested promo codes and invoice metadata can be abused quietly for weeks before a finance review catches the anomaly.

What to do this week — a 5-step check that takes under an hour

You do not need an enterprise vault project to close the immediate risk. Do these five things in order:

1. Check whether your .env is public

From an unauthenticated browser or with curl, request:

https://yourdomain.com/.env
https://yourdomain.com/.env.example
https://yourdomain.com/.git/HEAD
https://yourdomain.com/debug

All should return 404 or 403. If any returns 200 with key-value content, your file is exposed. Fix this at the server or CDN layer immediately — block dotfiles, restrict document root to public/, and ensure error pages do not dump $_ENV or process.env.

On Cloudflare, this is a one-rule fix: block /.env* and /.git/* at the edge. Leave /.well-known alone — it is meant to stay public for security.txt, SSL validation, and similar files. On Nginx/Apache, ensure .env is outside the served directory, not inside it.

2. Rotate your Stripe secret key — then invalidate the old one

In the Stripe Dashboard, go to Developers → API keys, roll the Secret key, and immediately revoke the previous value. This is a 2-minute task but it is the only step that actually invalidates a key that may already have been copied.

If you use restricted keys, roll those too — and check whether any key was created with overly broad permissions (the leaked samples included standard-type keys with full charge access).

3. Inventory every place the key lives

A key that was exposed in .env is often also in places scanners cannot see but attackers can reach after an initial foothold:

• .env files committed to private repos that later became public
• CI/CD logs and build artifacts
• Backup snapshots of the app directory
• Staging and legacy subdomains that share the same key (staging.yourdomain.com/.env)
• Third-party deployment tools that sync environment variables

Make a list of every location that has ever stored sk_live — then treat each one as a location to rotate and clean, not just the production server.

4. Scope keys to the least privilege you actually use

If your integration only needs to create PaymentIntents and read customers, it does not need a full Secret key with refund and payout write access. Stripe's restricted keys let you narrow scope by resource and method. Narrowing the key does not prevent exposure, but it limits what a copied key can do — and that difference between "read-only customer data" and "charge + refund" is the difference between a privacy incident and a financial one.

5. Check logs for anomalous Stripe API activity

After rotating, review Stripe's API request logs for the past 30 days (Developers → Logs) and your server access logs for:

• Unusual GET /.env or POST /.env patterns from scanner user-agents
• Stripe API calls from IPs or ASNs you do not recognize, especially POST /v1/refunds or POST /v1/payouts
• High-volume customer or invoice listing calls outside your normal integration behavior

If you find unfamiliar calls, treat it as an active incident — notify your payment processor, preserve logs, and consider a focused security review of the window in which the key was valid.

Making secrets less brittle — without going enterprise

The longer-term lesson is not "never use .env" — it is "treat .env as a secret store with an expiry date."

For small teams, three habits cover most of the risk:

• Time-box secrets. Give every secret a rotation date — Stripe keys every 90 days, database URLs every 180 days — and put it in the same calendar you use for domain renewal. The Stripe case shows that stolen credentials remain useful for weeks or months unless they are actually rotated.
• Keep secrets out of the repository. .env belongs in the server and the secrets manager, not in Git. If you use Git, add .env to .gitignore and scan history for accidental commits (tools like GitGuardian or TruffleHog do this in CI).
• Maintain a live inventory. Hudson Rock's analysis of the LiteLLM/PyPI supply-chain breach — where CloudSEK initially tracked roughly 434,000 CI/CD pipelines potentially exposed and Hudson Rock's independent analysis corroborated the scale at about 2,500 organizations — made the same point: removal of a tainted package does not end the incident — copied credentials outlive the file that exposed them. The inventory of where each secret lives is what lets you rotate quickly when any one location leaks.

These are the same practices Doppler's Breach Dashboard highlights across recurring secrets breaches. Two long-lived exposures are still cited as cautionary tales — CircleCI (January 2023, an engineer's infostealer-caught session cookie led to customer secrets) and Toyota (2017–2022, a hardcoded key sat in public GitHub for five years). Alongside them are two disclosures from the same month in 2026: Nx Console, a poisoned VS Code extension (version 18.95.0 published May 18, 2026, more than 2.2 million installs) that harvested developer secrets on workspace open; and CISA's own public GitHub repo holding roughly 844 MB of production infrastructure secrets, also dated May 2026 and reportedly exposed for about six months before takedown. The pattern is consistent: the breach starts with a secret that lived too long in the wrong place.

The bottom line

The Stripe vendor leak is a reminder that your checkout flow's security does not end at the Stripe Dashboard. It includes the file that holds the key to that dashboard — and that file, .env, is scanned by bots every day.

Check whether it is public. Rotate the key. Inventory where it lives. Scope its permissions. Review the logs. That is an hour of work that turns a potential financial exposure into a verified non-event — and it is the same hour that 669 vendors now wish they had spent before August 18.

Not sure what your store's security exposure looks like from the outside? WardenBit's free scanner checks 40+ categories — .env and .git exposure, SSL, security headers, CMS detection, email authentication, and more — in under 60 seconds. Run a free scan →