Magecart Attack Uses Stripe as Malware Command Server

A new form of credit card skimming malware has been identified, operating discreetly within one of the internet’s most trusted payment platforms.

Researchers have found a Magecart attack that uses Stripe, the widely used online payment service, as both its command center and its data dump.

Instead of pointing stolen card data to a shady server, attackers are routing everything through infrastructure that online stores already fully trust.

What makes this attack especially dangerous is how invisible it is to most security tools. The malware never loads from a domain the attacker owns.

Instead, both the payload and the stolen card data travel through api.stripe.com, a domain that virtually every e-commerce store allows by default. That means the traffic filters and security policies that would normally catch a skimmer simply let this one pass through.

Analysts at Sansec, a firm specializing in e-commerce security, identified this Magecart family and published their findings on June 4, 2026.

According to a Sansec report shared with Cyber Security News (CSN), Sansec said the attacker stores the card-stealing code inside a Stripe customer’s metadata, then runs it on checkout pages before writing stolen card numbers back into the same account disguised as fake customers. Stripe is being used as free criminal infrastructure.

The attack also relies on Google Tag Manager to deliver its initial loader. Real GTM containers, including one identified as GTM-P6KZMF63, were planted with a custom tag and served directly from googletagmanager.com.

This lets the loader blend in alongside a store’s legitimate analytics tags, making it much harder to detect without a careful manual audit.

The campaign appears to have been running since at least December 2025, based on the creation date of the Stripe account used in the attack.

The record was created on December 24, 2025, using what looks like a default template from Stripe’s own sample data, complete with a placeholder name and email address.

New Magecart Attack

The malware splits its work into three steps. First, the loader embedded inside a real GTM container fires on every page it loads.

When it detects a checkout page, it reaches out to a specific Stripe customer record controlled by the attacker and pulls down the skimmer code in chunks stored across multiple metadata fields.

Once downloaded, the skimmer attaches itself to the checkout button and waits. The moment a shopper clicks to complete a purchase, it captures the full card number, expiration date, CVV, billing address, and order total.

That data is then XOR-encoded and quietly stored in the browser’s local storage rather than being sent right away.

The actual theft happens on a delay. A separate routine checks for stored card data one second after each page load, and again every 60 seconds after that.

When it finds a record, it splits the data in half and posts it to Stripe’s customer API as a fake entry. The attacker can later retrieve all stolen cards by simply listing customers in their own Stripe account.

A Second Variant Using Google Firestore

Sansec also found a related variant that swaps Stripe for Google Firestore, Google’s cloud-hosted database service.

This version pulls its skimmer payload from a Firestore document inside a project named braintree-payment-app, a name chosen to look like normal payment traffic and avoid raising any flags.

Both variants follow the same core idea: abuse a mainstream, trusted cloud service as a hidden channel that no standard security rule would block.

The Firestore variant shows the attacker group is actively building out multiple delivery channels for their skimmer toolkit.

Sansec recommends that store owners audit all client-side scripts for any Stripe secret keys, since no legitimate front-end code ever carries one.

Any api.stripe.com or firestore.googleapis.com calls found in browser JavaScript should be treated as a sign of compromise. Store owners should also review every tag inside their Google Tag Manager account and remove anything they did not personally add.

Indicators of Compromise (IoCs):-

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.