Over 50,000 Stripe API keys belonging to merchant accounts have been discovered exposed in various public locations, including code repositories, build logs, and misconfigured web servers. This widespread exposure poses significant risks, as these "secret keys" grant full API access, enabling fraudsters to access customer data, initiate fraudulent transactions, and potentially redirect payment notifications.
Researchers from Ransomnews identified over 50,000 unique keys and conducted practical tests on a sample, confirming that a substantial portion remained active. They demonstrated that an active key could be used to access a merchant's customer list, create a fraudulent payment link, and make a test charge within 17 hours.
A dataset posted on a data-trading forum on August 18, 2026, reportedly contained live Stripe API keys for 659 merchant accounts, along with approximately 35 GB of associated customer and payment data. Ransomnews analyzed this dataset offline and reported their findings to Stripe prior to public disclosure. Stripe itself was not compromised; the exposed keys belonged to its merchant customers.
The sources of these leaked keys are varied but common in developer security incidents. Public and accidentally public GitHub repositories are a primary culprit, often due to hardcoded keys in configuration files, `.env` files committed without proper `.gitignore` entries, or keys left in code comments. GitHub Actions build logs are another significant source, where environment variables, including unmasked secrets, can be printed and become accessible to anyone with repository access. Misconfigured web servers also contributed, with over 3,000 servers found revealing Stripe-related strings, and about 12% of those containing active keys.
The specific origin of the 659 merchant keys in the data-trading forum dataset is not definitively known, but likely includes infostealer logs from developer machines, public repositories, exposed environment files, and misconfigured backups. The researchers noted that the individual who compiled this dataset demonstrated a high level of effort by systematically validating the keys, accessing each account, and organizing the stolen data.
Stripe's documentation indicates that the company actively scans for exposed merchant keys in repositories and package registries. It also offers an automatic secret scanning program through GitHub, which can flag Stripe keys in public repositories and, if a merchant opts in, trigger automatic revocation. However, the opt-in rate for this program is reportedly low, and it does not cover private repositories, build logs, web server misconfigurations, or other platforms where keys might surface.
Further complicating matters, some merchants who had rotated their keys after a GitHub exposure reportedly left the old, compromised keys active. Stripe does not automatically revoke old keys upon rotation unless they are explicitly deleted by the merchant.
To mitigate these risks, merchants are advised to audit their current Stripe keys against their version control history for any past exposure. Any key that has been committed to a public repository, appeared in a build log, or was present in an unprotected configuration file should be rotated. Additionally, merchants should enable Stripe's restricted keys for integrations that do not require full account access, such as webhook handlers. Implementing Stripe Radar rules to detect unusual charge patterns can also help identify potential unauthorized key usage before significant damage occurs.
