Leaked Stripe Merchant API Keys Expose Payment and Payout Capabilities

Key Takeaways

• Hundreds of active Stripe merchant API keys have been leaked and posted on a data-trading forum.
• This exposure affects 659 merchant accounts and approximately 688,000 individuals, compromising sensitive payment and customer data.
• The incident is not a breach of Stripe’s systems but rather a credential exposure originating from merchant environments.
• Leaked keys grant attackers extensive control, including initiating payments, issuing refunds, and altering payout destinations.
• Immediate action is required for affected merchants, including key rotation, review of security logs, and tightening access controls.

Hundreds of Stripe Merchant API Keys Exposed in Significant Leak

A substantial leak of active Stripe merchant API keys has created a critical security risk for numerous online businesses and their customers. The compromised credentials, capable of enabling unauthorized access to payment and payout functionalities, were made publicly available on a data-trading forum on August 18.

The leaked dataset, totaling approximately 35 GB, encompasses customer and payment information derived from 659 distinct merchant accounts. This exposure potentially impacts around 688,000 individuals. Importantly, this incident does not stem from a breach of Stripe’s core infrastructure but rather from the compromise of individual merchant keys.

RansomNews said in a report, which was shared with Cyber Security News (CSN), that their analysts conducted an offline examination of the leaked material. They proactively notified Stripe prior to public disclosure, specifically to avoid direct access to the exposed payment records during their investigation.

This event underscores the severe consequences of credential exposure, which can lead to large-scale account takeovers without requiring a sophisticated platform exploit or malware infection. The stolen keys likely originated from various sources, including information-stealing malware logs, publicly accessible code repositories, misconfigured environment files, or inadequately secured backups.

Deep Dive into the Leaked Data

Contrary to initial forum claims suggesting a direct hack of Stripe, investigations revealed a different scenario: an actor acquired numerous merchants’ secret API keys, validated their authenticity, and then utilized standard API requests to harvest data available through each compromised account. The archive was subsequently posted for free, rather than being offered for sale.

Out of the 659 validated credentials, 650 were identified as live secret keys, while nine were restricted keys. Each merchant folder within the archive reportedly contained up to 27 distinct resource types. These included sensitive records such as customer details, charge data, payment intents, invoices, refunds, disputes, subscriptions, payouts, product information, and balance transactions.

A secret API key provides far more than mere login access; it grants programmatic control over an account. This level of access enables an attacker to read customer data, initiate charges, process refunds, and critically, modify payout destinations. Analysis of the collected records indicated that 519 of the accounts had capabilities for both accepting payments and sending payouts, presenting a direct pathway for financial theft.

The credibility of the archive was further reinforced by its adherence to Stripe’s standard object formats. Researchers observed correct prefixes for various record types, including account, customer, charge, payment-intent, checkout-session, dispute, and request. Specifically, production checkout sessions utilized the cs_live_ format, and account identifiers followed the acct_ pattern, details that are challenging to convincingly forge.

The ramifications of this leak extend beyond the directly impacted businesses. The exposed customer information could be leveraged for various malicious activities, including identity fraud, social engineering attacks, and further account compromises. This incident highlights the persistent danger posed by the growing market for stolen credentials, where a single developer secret can become the entry point to valuable commercial systems.

What You Should Do

• Rotate All Live Secret Keys: Immediately change every live secret key within your Stripe account dashboard.
• Review API Request History: Scrutinize your security history for any API requests that are unusual or cannot be attributed to legitimate activities.
• Inspect Payout Settings: Carefully examine payout settings and associated bank details for any unauthorized modifications. Redirecting payouts is a common tactic for financial theft.
• Implement Restricted Keys: Replace broad secret keys with restricted keys. These keys should only possess the minimum permissions necessary for specific integrations.
• Apply IP-Based Access Policies: Where feasible, configure IP-based access policies for your API keys. This significantly reduces the utility of a stolen credential if an attacker attempts to use it from an unauthorized location.
• Audit for Leaked Secrets: Conduct thorough searches across code repositories, container images, CI/CD logs, backup storage, and environment files (e.g., .env files) for any inadvertently exposed secrets.
• Utilize Automated Secret Scanning: Implement automated tools for continuous secret scanning within your development and operational pipelines.
• Employ Secure Vaulting: Store API keys and other sensitive credentials in secure, encrypted vaults rather than hardcoding them or leaving them in plain text.
• Regular Key Rotation: Establish a policy for regular rotation of all API keys, even those not believed to be compromised, to minimize the window of exposure for any potential future leaks.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.