What Is the Stripe-Hosted Skimmer Hack and How to Detect It

– When Attackers Hide Inside Tools You Already Trust

A recently uncovered Magecart campaign shows why you can’t trust ‘trusted’ tools anymore. Instead of reaching out to an attacker-controlled site, this new skimmer hides inside two services nearly every online store treats as safe: Stripe and Google Tag Manager.

This is troubling for website owners because it bypasses traditional security controls.

What actually happened

Researchers at Sansec identified a card-skimming operation that uses Stripe’s own API infrastructure as both a hiding place and a delivery channel for stolen data. The attack has been running since at least late December 2025 and targets checkout pages on Magento and Adobe Commerce stores.

It delivers the malicious code through a Google Tag Manager container, the same mechanism marketing teams use to add analytics and tracking scripts without touching the site’s code. When a shopper reaches checkout, that code pulls a hidden payload out of a customer record stored in the attacker’s Stripe account and runs it in the shopper’s browser.

From there, it does what skimmers do: it captures the card number, expiration date, CVV, cardholder name, billing and email addresses, and phone number as the buyer types them. But rather than firing the data off immediately to a suspicious server, it scrambles the information and parks it in the browser’s local storage. A separate routine then checks for stolen data one second after each page load, and again every 60 seconds, and smuggles it out by creating fake customer records inside the attacker’s Stripe account.

In effect, this attack turns a legitimate payment platform into a data warehouse and then wipes the local traces to keep the theft quiet. A second version of the campaign uses Google Firestore in the same way.

One detail gives it away

There is one telltale sign hiding in plain sight. Each loader carries a hardcoded Stripe secret key, the kind that begins with sk_. No legitimate integration ever ships a Stripe secret key in client-side JavaScript; secret keys belong on the server. Finding one in a browser script is, by itself, proof of compromise. If your team audits front-end code for nothing else this quarter, audit for that.

Why this one matters more than the average breach story

The clever part isn’t the code. It’s the choice of address. Both api.stripe.com and Google Tag Manager are domains that virtually every e-commerce site allows by default. They have to; Stripe processes the payments, and Tag Manager runs the marketing stack.

That single design decision lets the attack slip past defenses that would normally catch a skimmer because:

It defeats allowlists and content security policies. These controls work by blocking traffic to domains you haven’t approved. When the malicious traffic flows through Stripe (a domain you not only approved but depend on), there’s nothing for those rules to flag.

It’s invisible to server-side and perimeter tools. Firewalls, vulnerability scanners, and the security checks built into your release pipeline are all designed to protect the server and the network. This attack never touches them. Everything happens inside the customer’s browser, after your page has loaded perfectly and after every server-side check has passed clean.

It blends into legitimate traffic. A connection to a payment processor during checkout is exactly what you’d expect to see. Nothing looks out of place, which is precisely the point.

The result is an attack that can run for months on a checkout page that appears completely healthy, while quietly bleeding customer payment data. The first sign of trouble often arrives as fraud reports, chargebacks, or a call from your acquiring bank.

The business and compliance stakes

The damage from web skimming isn’t limited to the cards stolen. There’s also brand trust, customer churn, fraud liability, and the regulatory fallout.

It’s also why PCI DSS v4, mandatory since 2025, added requirements 6.4.3 and 11.6.1 to address this blind spot. They now oblige merchants to maintain an inventory of every script running on payment pages, justify why each one is there, and detect unauthorized changes or tampering, for first-party and third-party scripts alike. The regulation exists because the industry recognized that the browser is now where payment data gets stolen, and traditional controls were never built to see it.

A campaign like the Stripe skimmer is exactly the scenario those requirements were written for. Meeting them is the difference between catching this kind of attack early and discovering it months later.

How Reflectiz addresses it

The reason this attack works is that conventional defenses ask the wrong question: where is the traffic going? But a trusted domain always passes, so what they should be asking is: what is this script actually doing?

That behavioral question is what Reflectiz is built to answer. Instead of judging a script by where it loads from or matching it against a list of known-bad signatures, Reflectiz watches how every script actually behaves once it’s running in the browser, including the ones loaded from trusted sources like Stripe and Google Tag Manager.

It keeps track of which scripts touch the card number and CVV fields, how each one behaves during checkout, and where the information they handle ends up. When a component that has every reason to be on your page suddenly starts reading payment fields or moving data in a way it never used to, that’s the anomaly Reflectiz flags, regardless of how trusted the source is or whether the code is obfuscated.

Here’s why it works so well:

It sees what your other tools can’t. Reflectiz monitors the live browser experience your customers actually get, covering what WAFs, scanners, and CSP rules can’t.

It covers the whole journey, not just checkout. Skimmers increasingly activate on product, account, or login pages too, so Reflectiz monitors all of them.

It governs your tag managers. Because this campaign entered through GTM, continuous tag manager security matters: Reflectiz inventories every container and tag and flags any that appear without authorization.

It deploys without touching your site. Reflectiz works remotely through its own sandboxed browser; no code changes, no agent, and no new scripts added to your payment pages.

It maps directly to PCI DSS 4.0.1. The platform automates the script inventory, approvals, and integrity monitoring that requirements 6.4.3 and 11.6.1 demand, and produces audit-ready evidence without accessing any payment data.

To be clear, none of this replaces your WAF, secure coding practices, or vendor risk management. Those controls remain essential. But this campaign is a working demonstration that they cannot see the browser layer, and the browser layer is where the theft happened.

Indicators of compromise

If you run a Magento or Adobe Commerce store, check for these artifacts from Sansec’s research:

• GTM container IDs: GTM-P6KZMF63, GTM-55976FLP, GTM-MSDHV3HG, GTM-TV4CSHVN
• Exfiltration endpoints: api.stripe.com/v1/customers and a Firestore document under the project braintree-payment-app
• localStorage keys: cus_customer_id and d_data_customer
• Any Stripe secret key (sk_ prefix) in client-side JavaScript

Also review every tag in your Google Tag Manager account and remove anything your team did not add.

The takeaway

This campaign is a preview of where web threats are heading. It’s less about breaking in and more about borrowing the trust you’ve already extended to your vendors. As long as everyone keeps thinking “trusted domain” means “safe,” attackers will keep routing their operations through services you can’t afford to block. And as a recent campaign that didn’t even bother with obfuscation proved, they’re confident nobody is watching the browser.

That’s why it’s best to stop trusting code based on where it comes from and start verifying what it does, continuously, in the live browser, for every script on every page. That’s the visibility this attack was designed to evade, and it’s the visibility Reflectiz is built to provide.