A new Magecart campaign is using Stripe’s API infrastructure to host the credit card-stealing payload and the data exfiltrated from checkout pages.
The entire malicious activity relies on Google Tag Manager and Stripe domains – googletagmanager.com and api.stripe.com – that are trusted implicitly by online stores.
The new malware family was discovered by researchers at ecommerce security company Sansec, who found that the malicious code is loaded from a Google Tag Manager (GTM) container and executes on every page that loads it.
“Both the payload and the stolen cards move through api.stripe.com. Stores allow that domain by default, so the skimmer slips past Content Security Policy rules and network filters that would otherwise flag traffic to an unknown skimmer domain,” Sansec says.
GTM is a management system that allows website owners to add and manage scripts used for analytics, ads, and tracking, without modifying the site’s source code.
Stripe is a payment processing platform widely used by online stores to accept credit cards, manage customer orders, and handle billing.
According to Sansec, the malicious code is embedded in legitimate-looking GTM containers, which activate when a shopper reaches a checkout page, queuing Stripe’s API for a specific customer record, cus_TfFjAAZQNOYENR, in this case
From the metadata fields of the record, it reads JavaScript code that it reassembles and then executes using new Function().
The card skimmer targets Magento/Adobe Commerce checkout pages and attempts to capture payment data (credit card number, expiration date, CVV code, customer name) as well as billing and email addresses, and phone number.
Source: Sansec
The stolen data is concatenated into a single string, obfuscated using the XOR operation, and stored locally instead of immediately exfiltrated.
Retrieving the data is done through a separate routine, which executes right after a page load and every minute after, by splitting the data blob in half, creating a new Stripe customer object, and storing 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.
Once the data is copied, the local file is wiped to eliminate traces of the attack and prevent duplicate uploads.
Source: Sansec
Sansec also discovered a variant of the attack where Google Firestore, a cloud database service for data storage and real-time retrieval, is used instead of Stripe.
In that version of the campaign, the payload is retrieved from a Firestore document named tracking/captcha in a project called braintree-payment-app. The stolen data is stored in a different localStorage key (_d_data_customer_).
The names of the document and the project help the malware blend in with legitimate payment and bot-protection traffic.
The Stripe customer record containing the skimmer was reportedly created on December 24, 2025, suggesting that the operation may have been active since at least that date.
Customers can protect themselves from such risks by using one-time virtual cards with set limits.
Security teams log 54% of successful attacks and alert on just 14%. The rest move through your environment unseen.
The Picus whitepaper shows how breach and attack simulation tests your SIEM and EDR rules so threats stop slipping by detection.
