50,000 Leaked Keys. One Line of Code. Your Payment Data at Risk.

Here's a scenario that should concern every business leader: a developer on your team writes code that processes payments. They hardcode an API key into the application — just temporarily, they tell themselves — and push it to a code repository. Maybe it's a public GitHub repo. Maybe it's an internal one that gets misconfigured. Maybe it ends up in a CI/CD build log that anyone with repo access can read.

Within hours, an attacker finds that key. Within 17 hours, they've accessed your customer list, created a fraudulent payment link, and made a test charge against a real account.

This isn't theoretical. This is exactly what happened — at scale — to over 659 real businesses this week.

What Happened: 50,000 Keys, One Data Trading Forum

On August 18, 2026, researchers at Ransomnews documented a massive exposure of Stripe merchant API keys. The numbers are stark: over 50,000 unique Stripe API keys identified in public code repositories, GitHub Actions build logs, and misconfigured web servers. Of those, 659 live merchant keys were collected into a dataset and posted freely on a cybercrime data-trading forum.

Those 659 keys came with something far more damaging: approximately 35 GB of customer and payment data exported directly through Stripe's API — including customer records for an estimated 688,363 individuals across 42 countries. Names, addresses, payment history, transaction records. All of it pulled using the merchants' own legitimate API credentials.

Stripe itself was not breached. Its infrastructure is fine. The breach was entirely on the merchant side — businesses whose developers inadvertently exposed the keys that control their Stripe accounts.

The researchers tested their findings. Starting from a single active API key, they were able to access a merchant's full customer list, create a fraudulent payment link, and execute a test charge — in 17 hours. That's the window between "key exposed" and "active fraud."

Why Developer Secrets Are a Business Problem, Not Just an IT Problem

Most business leaders think of payment security as a vendor responsibility. You sign up for Stripe, Stripe handles the security, done. And Stripe does handle an enormous amount — their infrastructure is world-class.

But the API key is your responsibility. It's the credential that grants access to your Stripe account. And API keys live in your code, your build pipelines, your configuration files, your developers' laptops. That's your environment, your risk, your exposure.

The sources of the leaked keys are painfully predictable:

Public GitHub repositories are the largest source. A developer hardcodes a key into a configuration file. They push it to a public repo — maybe accidentally, maybe because the project started as public and was never properly reviewed. The key is now indexed by GitHub, by Google, and by dozens of automated scanners that threat actors run 24/7 specifically to find exposed credentials.

GitHub Actions build logs are the second major source. When a CI/CD workflow prints environment variables for debugging — a common development practice — any secret that wasn't properly masked ends up in a log. And anyone with repository access can read those logs.

Misconfigured web servers and cloud storage round out the list. An .env file accidentally exposed via a web root. An S3 bucket with public read permissions containing a backup that includes configuration files. A container image built with secrets baked in.

None of these are exotic attack techniques. They're the natural consequence of developer workflows that treat secrets as convenient configuration values rather than high-value credentials requiring systematic protection.

The Blast Radius Goes Beyond Stripe

The Stripe exposure is the most visible part of this problem, but it's not the whole picture. The same developers who expose Stripe keys also work with AWS credentials, database passwords, third-party SaaS API keys, internal service tokens, and dozens of other secrets.

When Ransomnews identified the 659 live Stripe keys, they found a dataset that included not just Stripe payment data, but surrounding files that suggested the keys were pulled from environments with access to much more. The likely sources — infostealer logs, compromised CI/CD pipelines, exposed environment files — are the same vectors that lead to cloud account takeover, database exfiltration, and lateral movement into production systems.

A leaked API key is rarely just a leaked API key. It's a window into the environment that produced it.

The Speed Problem

Here's what makes this urgent: the timeline is not on your side.

Automated scanners find exposed GitHub credentials within minutes of a commit being pushed. The keys are validated against live APIs in bulk — thousands of checks per minute. The live ones are catalogued. From there, the path to active fraud or data access is measured in hours, not days.

The Ransomnews research showed a 17-hour window from key discovery to fraudulent charge. Other research on exposed credentials consistently shows that live keys are exploited within 24 hours of exposure in most cases. The patch-cycle mindset — where you have weeks to respond to a disclosed vulnerability — does not apply to exposed secrets. The exposure window begins the moment the commit is pushed.

Three Questions Every Business Leader Should Ask

You don't need to understand GraphQL or GitHub Actions to protect your business. But you do need to ask these questions of your technology team right now:

1. Do we have secret scanning in our development workflow? Modern development platforms — GitHub, GitLab, Azure DevOps — have built-in secret scanning that alerts on exposed credentials before they're committed, or flags them immediately after. This is not a complex or expensive control. If your team isn't using it, ask why.

2. Do we have a credential rotation policy, and can we execute it fast? When a credential is exposed — whether through a leak, a breach, or a suspicious indicator — the response needs to be measured in hours, not weeks. Do you know which API keys your business is using? Do you know who owns each one? Can you revoke and rotate them without breaking production? If any of those questions produce a long pause, you have a gap.

3. Have we audited our exposure surface in the past 90 days? There are tools — both free and commercial — that can scan your repositories, CI/CD logs, and cloud storage for exposed secrets. If you haven't run that kind of audit recently, you may have keys sitting in public code right now.

The Broader Pattern

This week's Stripe exposure is a useful reminder of something that tends to get lost in the noise of zero-days and nation-state threats: a significant portion of breaches come down to secrets that weren't treated as secrets.

The 50,000 exposed keys weren't stolen through sophisticated exploitation of a Stripe vulnerability. They were found in places they should never have been — pushed there by developers under deadline pressure, working without the right tooling, operating in organizations that never built secrets management into their development culture.

That's a solvable problem. It doesn't require a seven-figure security budget or a team of specialists. It requires clear policies, the right tooling in the development pipeline, and leadership that treats secrets hygiene as a business requirement rather than an IT afterthought.

The businesses affected this week learned that lesson the hard way. You don't have to.

Where TrustPoint Cyber Can Help

TrustPoint Cyber works with businesses to close credential and secrets exposure gaps — from development pipeline assessments to secrets management implementation to incident response planning. If you're not sure whether your organization has exposure, the right time to find out is before someone else does.