"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.
How the Magecart campaign uses Google Tag Manager and api.stripe.com
Researchers at ecommerce security company Sansec discovered a new Magecart campaign that weaponizes two domains commonly trusted by online stores: googletagmanager.com and api.stripe.com. The attack hides its skimming code inside legitimate-looking Google Tag Manager (GTM) containers, which many stores use to add analytics, ads, and tracking scripts without changing site source code. When a visitor reaches a checkout page, the malicious GTM container queues a call to Stripe's API for a specific customer record (cus_TfFjAAZQNOYENR in the observed case), and both the skimmer payload and the exfiltrated payment data are routed through api.stripe.com.
Technical mechanics: payload retrieval, execution, and storage
Sansec reports that the malicious GTM container activates on every page that loads it but specifically triggers during checkout. From the metadata fields of the queued Stripe customer record, the skimmer reads JavaScript code, reassembles it, and executes it using new Function(). The malware targets Magento/Adobe Commerce checkout pages and captures payment details (credit card number, expiration date, CVV), customer name, and billing and contact data (email and phone number).
Rather than immediately exfiltrating data to a remote server, the skimmer concatenates the stolen fields into a single string, obfuscates that blob with an XOR operation, and writes it to local storage. A separate routine then runs right after page load and at one-minute intervals: it splits the stored data blob in half, creates a new Stripe customer object in the attacker's Stripe account, and puts the stolen data into the customer's metadata fields. After copying the data into Stripe, the local file is wiped to remove traces and avoid duplicate uploads. In effect, each stolen payment card becomes a fake customer record inside the attacker's Stripe account, turning Stripe into a storage backend for stolen data.
Firestore variant: tracking/captcha and braintree-payment-app
Sansec also documented a variant that uses Google Firestore instead of Stripe as the back-end store. In that campaign version the payload is retrieved from a Firestore document named tracking/captcha inside a project called braintree-payment-app. Stolen data is written to a different localStorage key (_d_data_customer_). Sansec notes the choice of document name and project helps the malware blend with legitimate payment and bot-protection traffic.
What this means for technologists, affected enterprises, and end users
- Technologists and security teams: be aware that GTM containers and trusted payment domains can be abused. Because most stores allow api.stripe.com by default, traffic to that domain is less likely to be flagged by Content Security Policy and network filters; defenders need to monitor GTM container contents and unexpected Stripe customer records or metadata activity.
- Affected enterprises and procurement leaders: the compromise chain here does not rely on a novel zero-day but on abusing trusted operational tooling (GTM) and trusted service endpoints (Stripe API, Firestore). Inventory and governance of third-party tags and tighter controls on what containers are published to production checkout pages will be decisive.
- End users and customers: Sansec's report points to a practical mitigation available to shoppers: using one-time virtual cards with set limits can reduce exposure if a merchant's checkout is compromised.
Detection, reporting, and the observed timeline
Sansec reported that the Stripe customer record that contained the skimmer was created on December 24, 2025, suggesting the operation may have been active since at least that date. The campaign succeeds in part because stores implicitly trust the domains involved; that trust lets the skimmer slip past Content Security Policy and network filters that would otherwise flag unknown skimmer domains. In a related note cited by the source, security teams log 54% of successful attacks and alert on just 14%, a gap Picus characterizes in its whitepaper as one that breach-and-attack simulation can help close by testing SIEM and EDR rules.
The attack is notable not for exotic tooling but for turning legitimate infrastructure into covert storage and delivery channels: GTM to deliver code, and either Stripe customer metadata or a Firestore document to store card data. The chain—malicious GTM container → metadata-hosted payload → local obfuscated storage → Stripe/Firestore metadata upload—transforms everyday platform convenience into a conduit for theft. Defenders, merchants, and shoppers now have a clear, tangible set of artifacts to watch for: unexpected GTM container changes, suspicious Stripe customer records (especially newly created ones carrying unusual metadata), and Firestore documents named to blend with payment tooling.
