Credit card theft campaign abuses Stripe to host stolen payment info By Bill Toulas June 4, 2026 04:47 PM 0 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. Card skimmer code 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. Data exfiltration routine 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. Test every layer before attackers do 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. Get the whitepaper Related Articles: Hackers use pixel-large SVG trick to hide credit card stealer Funnel Builder WordPress plugin bug exploited to steal credit cards Škoda warns of customer data breach after online shop hack SAP fixes critical vulnerabilities in Commerce Cloud and S/4HANA NGate Android malware uses HandyPay NFC app to steal card data
A new Magecart campaign abuses the trusted domains of Google Tag Manager and Stripe's API to host and exfiltrate stolen payment card data from checkout pages. The skimming payload is loaded from a compromised GTM container and uses Stripe's customer metadata fields to store both its malicious code and the stolen data, effectively bypassing common Content Security Policy rules and network filters. The attack targets Magento/Adobe Commerce checkout pages, capturing full payment details and storing them locally before exfiltration via the creation of fake customer records in the attacker's Stripe account.