659 live Stripe keys and 35GB of payment data for sale: scanning is now a fraud control

A dataset offered on a data-trading forum on 18 August 2026 contains live Stripe API keys for 659 merchant accounts along with roughly 35 GB of customer and payment data pulled from them, according to research published by Ransomnews ^[1]. That listing sits on top of a larger inventory the same team documented: more than 50,000 unique Stripe merchant keys exposed in public code repositories, GitHub Actions logs and misconfigured web servers ^[2].

Stripe itself was not compromised. The keys belong to merchants, and Ransomnews says it analysed the files offline and reported the exposure to Stripe before publishing ^[3].

What moves this out of the hygiene column is time-to-money. After finding one active key, the researchers reached a merchant's customer list, created a fraudulent payment link and put through a $1 test charge within 17 hours, with the key alone as authorisation ^[4]. A secret key is not a partial credential. Per the report it permits listing customers and their stored payment methods, creating charges and payment intents, issuing refunds to attacker-controlled accounts, modifying webhook endpoints to intercept future payment notifications, and in some cases reaching connected accounts where the merchant had enabled Stripe Connect ^[5].

The leak paths are ordinary, which is the point. GitHub repositories, both public and accidentally made public, account for the largest share, typically hardcoded keys in configuration files, .env files committed without a corresponding .gitignore entry, or keys left in code comments ^[6]. GitHub Actions build logs are second: a workflow that prints environment variables for debugging writes any unmasked secret into a log readable by anyone with repository access ^[7]. Ransomnews also found more than 3,000 servers revealing Stripe-related strings, about 12 percent of which contained keys that worked against the Stripe API ^[8], on the order of 360 servers handing out working payment credentials ^[9].

The scanning that exists does not cover the ground. Stripe participates in GitHub's secret scanning partner program, which flags Stripe keys in public repositories and can trigger automatic revocation when a merchant opts in, but Ransomnews describes the opt-in rate as low, with no coverage of private repositories, build logs, web server misconfigurations or other platforms ^[10]. The researchers also found merchants who rotated keys after a GitHub exposure and left the old key active, which the report attributes to Stripe not revoking keys on rotation unless the old one is explicitly deleted ^[11]. Rotation without deletion is not remediation.

The collector's advantage was patience rather than technique: gathering keys is common, while validating several hundred, systematically walking the API for each account and archiving the results into a consistent folder structure is a different level of effort, per the report ^[12]. Ransomnews declines to name a single origin for the 659 merchants, listing the realistic candidates as infostealer logs from developer machines, keys committed to public repositories, exposed environment files and misconfigured backups ^[13]. That averages out to roughly 54 MB of exported customer and payment data per victim merchant ^[14].

Watch whether merchants treat the report's remediation list as a payments task with an owner: audit current keys against version control history, rotate anything that has touched a public repository, a build log or an unprotected configuration file, and issue restricted keys to integrations that do not need full account access, since a webhook handler does not need the ability to create charges ^[15]. The report also points to Stripe Radar rules for flagging unusual activity ^[16].