1,033 Live Stripe Secret Keys Leaked: How Exposed .env Files Became a Payment Rail Breach
On August 18, 2026, a threat actor dumped 1,033 live Stripe sklive... keys from 669 vendors on an illicit forum — with a direct claim to Hudson Rock that ~20,000 keys are held for staggered release. The leaked keys had charge capabilities, were tied to real invoices and promo-code tables, and the victims ran completely different stacks. Hudson Rock found no infostealer infections tied to the vendor domains. The working hypothesis: automated mass-scanning for publicly exposed .env files and debug logs.
No vulnerability in Stripe. No single WordPress plugin. One misconfigured file, found at scale.
If you build or operate anything that talks to Stripe, this is a build-pipeline and deployment-hygiene incident you can verify in five minutes.
Per Hudson Rock's Infostealers analysis: 669 vendors, 1,033 sklive keys, customer rows, charges, balances, payouts, invoices Advertised 33 GB total; the provided archive was 2.37 GB — consistent with a staggered release JSON samples show "sklive51H..." with explicit charge-access flags Invoice-linked CSVs with customer name / email / phone / home address / IP at purchase / internal transaction IDs / third-party integration identifiers — plus hosted invoice URLs that resolve to valid Stripe invoices exposing last-four of card A separate promo-code spreadsheet (code, discount amount, duration) — mass abuseable
The 20,000 figure is an actor claim to Hudson Rock researchers, not an independent count. Treat it as claimed; the 1,033 observed keys are verified. That distinction matters if you cite the story.
That is programmatic access through normal Stripe API calls. No exploit. A scanner that finds the key gets the same interface your backend uses.
Two signals rule out a single-dependency explanation: Victim tech stacks are heterogeneous — PHP storefronts, Node services, Python APIs, hosted site builders. No common plugin or framework. Hudson Rock's telemetry found no infostealer infections on the specific vendor domains in the dump.
Both point to infrastructure-level exposure: a document root that serves dotfiles, a Docker image that copies .env into the served directory, or a debug/error page that dumps process.env / $ENV. Scanners for /.env, /.git/HEAD, and /debug are older than this breach and fully automated.
On Cloudflare, a single WAF custom rule blocking URI Path contains /.env or /.git covers the edge, but it is not a substitute for origin hygiene — the origin must not serve the file even if the edge is bypassed by direct IP.
If you use restricted keys, roll each one and audit whether any key was issued as a standard-type key with full charge + refund + payout scope when your integration only needs payment_intents:write and customers:read. Scope reduction after rotation:
A copied standard key and a copied restricted key are both breaches — but one can refund and reroute payouts, the other cannot. That scope boundary is the difference between a privacy incident and a financial one.
The .env on production is rarely the only copy. After rotation, inventory and clean: .env committed to a private repo that later became public CI logs and build artifacts that echoed environment Backup snapshots of the app directory (app-2026-03-01.tar.gz that includes .env) Staging / legacy subdomains sharing the same key (staging.yourdomain.com/.env) Third-party deploy tools and env-sync services that replicate variables Local .env files on developer machines that were never rotated after the exposure window
A single git log --all --full-history -- ".env" and a secrets scan (GitGuardian, TruffleHog, gitleaks in CI) catches most historical commits. The point of the inventory is speed the next time any one location leaks: you rotate the key once and every copy is covered.
After rotating, look backwards 30 days in both places: Stripe Dashboard → Developers → Logs: filter for POST /v1/refunds, POST /v1/payouts, and high-volume GET /v1/customers or GET /v1/invoices from unfamiliar IPs / ASNs. Normal integrations have a predictable call pattern; bulk listing is anomalous. Origin access logs: GET /.env and GET /.git/HEAD from scanner user-agents in the weeks before the dump date. Even a 404-heavy scan leaves a fingerprint.
If either log shows unfamiliar calls, treat the window as an active incident — preserve logs, notify the payment processor, and consider a focused review of the key's lifetime.
Doppler's Breach Dashboard timeline makes the pattern explicit. Recent examples include n8n (4,576 tokens found in public GitHub, 321 still valid, August 2026) and LiteLLM on PyPI — where CloudSEK initially tracked roughly 434,000 pipelines potentially exposed and Hudson Rock's independent analysis corroborated the scale at about 2,500 organizations (March 2026 backdoored releases 1.82.7/1.82.8) — alongside two disclosures from May 2026: Nx Console (poisoned VS Code extension 18.95.0 published May 18, more than 2.2 million installs) and CISA's own 844 MB public repo of production secrets (also May 2026, reportedly exposed for about six months). The Hudson Rock note on LiteLLM applies verbatim: removal of the file does not end the incident — copied credentials outlive the exposure.
For small teams, the durable fix is three habits rather than a vault project: Time-box secrets — Stripe keys every 90 days, DB URLs every 180, on the same calendar as domain renewal Keep secrets out of the repo — .env in .gitignore, history scanned in CI, BuildKit secrets or env injection at deploy time Maintain a live inventory of every location that holds each secret, so rotation is one action, not a scavenger hunt