Magecart skimmer hides in Stripe via GTM

Magecart skimmer – A Magecart-style campaign is using Google Tag Manager containers and Stripe’s trusted API domain to carry credit card skimming code and store stolen payment data inside fake Stripe customer records—while also using a Firestore-based variant for the same workfl

For shoppers, the moment is ordinary: they hit a checkout page and everything loads like it always has. For the attacker behind a new Magecart campaign, that same page view is the trigger.

Researchers at ecommerce security company Sansec say the skimming payload is loaded from Google Tag Manager (GTM) containers and runs on every page that loads the container. The malware relies on the trust online stores place in GTM and Stripe domains—specifically googletagmanager.com and api.stripe.com—domains that many merchants allow without friction.

Sansec’s core finding is blunt: both the payload and the stolen cards move through api.stripe.com. Because stores allow that domain by default, the skimmer can slip past Content Security Policy rules and network filters that might otherwise block traffic to an unfamiliar malicious endpoint.

Stripe, in this scheme, is more than a payment processor. Sansec describes how the malicious code embeds itself inside legitimate-looking GTM containers, activating when a shopper reaches a checkout page. It then queues Stripe’s API for a specific customer record—cus_TfFjAAZQNOYENR in this case.

From the metadata fields of that record, the malware reads JavaScript code, reassembles it, and executes it using new Function().

The campaign targets Magento/Adobe Commerce checkout pages. It attempts to capture payment data—credit card number, expiration date, and CVV code—along with customer name, billing and email addresses, and a phone number.

Once the data is captured, the attackers don’t immediately blast it out. Sansec reports the stolen data is concatenated into a single string, obfuscated using the XOR operation, and stored locally instead of exfiltrated right away.

The retrieval and laundering step happens continuously. A separate routine executes right after a page load and every minute after that. It splits the stored blob in half, creates a new Stripe customer object, and stores the stolen data in metadata fields.

Every stolen payment card becomes a fake customer record in the attacker’s Stripe account, turning Stripe into a storage backend for stolen data.

After the data is copied, the malware wipes the local file to eliminate traces and prevent duplicate uploads.

Sansec also found a variant of the attack where the same kind of workflow shifts away from Stripe storage. In that version, Google Firestore—a cloud database service for data storage and real-time retrieval—is used instead of Stripe. The payload is retrieved from a Firestore document named tracking/captcha in a project called braintree-payment-app. and the stolen data is stored in a different localStorage key (_d_data_customer_).

Even the names are built to blend in. The document and project names are meant to look like legitimate payment and bot-protection traffic.

The timing detail is what makes the risk feel immediate rather than theoretical. Sansec says the Stripe customer record containing the skimmer was reportedly created on December 24, 2025, suggesting the operation may have been active since at least that date.

For customers trying to reduce exposure, Sansec points to one-time virtual cards with set limits as a practical protection against card skimming.

Magecart Stripe api.stripe.com Google Tag Manager GTM skimmer credit card theft Magento Adobe Commerce Content Security Policy Firestore malware cybersecurity