Hackers Hid a Card Skimmer Inside Stripe’s Customer Database

Attackers have been storing a credit card skimmer inside Stripe’s customer database since at least December 2025, delivering the malicious JavaScript through a Google Tag Manager (GTM) container and routing stolen card data back through the same payment API, according to Sansec, an e-commerce security firm, whose Stripe API skimmer campaign analysis was published June 4. The campaign targets Magento and Adobe Commerce checkout pages, capturing card numbers, CVV codes, billing addresses, and phone numbers the moment a shopper submits payment.

Most online store Content Security Policies (CSP), the browser-side rules that block scripts from untrusted domains, include api.stripe.com and googletagmanager.com on their allowlists by default. Under those standard configurations, the skimmer’s traffic looks identical to a legitimate payment request.

How a GTM Container Hides a Card Skimmer

The attack runs in three stages, all routing through infrastructure the targeted stores already trust.

• A malicious GTM container is planted as a custom tag on a compromised Magento or Adobe Commerce store. Sansec traced one to container ID GTM-P6KZMF63, served directly from googletagmanager.com and visually indistinguishable from the legitimate analytics and advertising tags a normal store runs.
• On any page whose URL contains “checkout,” the container fires a request to a specific Stripe customer record under the attacker’s control. In the campaign Sansec analyzed, that record is cus_TfFjAAZQNOYENR. The malware payload is chunked across multiple metadata fields in that record; the loader reassembles the pieces and executes the assembled JavaScript using new Function(), running arbitrary remote code without placing any overtly suspicious code inside the GTM tag itself. Once the skimmer runs in the browser, it hooks the checkout button. When the shopper submits payment, it captures the card number, expiration date, CVV, billing address, and phone number. That data is XOR-encoded, a basic obfuscation cipher, and written to browser localStorage.
• A separate routine fires one second after the next page load, then every 60 seconds. It reads the stored blob, splits it in half, and posts each piece as metadata in a new fake customer entry in the attacker’s Stripe account. Once uploaded, the localStorage entry is deleted to prevent duplicate submissions. The attacker retrieves all stolen cards later by listing customers in their Stripe account with the same hardcoded API key.

The skimmer never makes a direct request to any domain the attacker owns.

The CSP Allowlist as Attack Surface

Content Security Policy works by declaration: site operators name the domains a browser may trust, and all others are blocked. Stripe and GTM sit on the allowlist of virtually every store that uses them. The browser, following its configured allowlist exactly, executes everything arriving from api.stripe.com, including this skimmer, and produces no alert.

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 published that in its June 4 campaign report.

The attacker’s code also carries a hardcoded Stripe secret key beginning with sk_test_, a server-side credential that no legitimate front-end integration contains. Finding it requires examining the assembled, executed payload after it runs in the browser. The MDN Web Docs guide on Content Security Policy notes that allowlist-based CSP configurations often inadvertently trust unsafe domains, recommending nonce-based or hash-based directives for stricter control over third-party script execution.

A Second Channel, Built for the Same Job

Sansec found a second variant of the loader that swaps Stripe for Google Firestore, Google’s cloud-hosted database service. In this version, the payload comes from a Firestore document path designed to blend into a payment-page context.

The project name is braintree-payment-app, after Braintree, the PayPal-owned payment processor, and the document path is tracking/captcha, a pattern associated with bot-protection flows. A firestore.googleapis.com request originating from a checkout page, pointing toward a project named for a payment processor and a document path matching an anti-bot pattern, draws no immediate suspicion from routine log review. And firestore.googleapis.com is a Google domain that clears the same CSP allowlists as googletagmanager.com.

The two variants share an identical core: a mainstream cloud service acts as both payload repository and exfiltration endpoint.

Building two channels, each disguised with payment-adjacent branding, points to a group actively expanding its evasion toolkit. A separate Stripe API abuse technique, documented by Jscrambler in a prior campaign, used a legacy Stripe endpoint to validate stolen card data before exfiltration, showing that payment infrastructure abuse has been an active avenue for Magecart operators for some time.

Five Months of Quiet Collection

The malicious Stripe customer record Sansec examined was created on December 24, 2025, using a default template from Stripe’s own getting-started documentation. “Jenny Rosen” is the placeholder name on the record; the email address uses a stripe.com domain, both fixtures of Stripe’s standard onboarding sample data that the attacker left in place.

That date puts the campaign at more than five months of operation before the June 4 disclosure. No count of affected stores accompanied the report.

Magecart groups, a loosely affiliated collection of criminal organizations responsible for payment data theft at British Airways, Ticketmaster, and thousands of smaller e-commerce sites since the technique was first documented around 2014, have moved steadily toward legitimate infrastructure as a hosting layer. Campaigns documented in 2022 and 2023 used compromised third-party retail websites as command-and-control servers, hiding malicious code behind a genuine merchant’s domain to avoid blocklists. Akamai’s analysis of that 2022 campaign found 9,290 digital commerce domains hit that year, with 2,468 still actively infected at year’s end. Storing a payload inside a live, licensed Stripe account is a further step in that direction.

The collection method gives the operation durability without the need for self-operated infrastructure. Stolen cards accumulate as browseable customer records in the attacker’s Stripe dashboard, accessible through a standard API listing call with the same hardcoded key. No separate server needs to stay running, and no domain needs to avoid detection.

Finding the Skimmer in Approved Traffic

Standard network monitoring tuned to flag connections to unknown or suspicious domains finds nothing here. Every request the skimmer makes is a well-formed, authorized API call to a domain the store explicitly permits. The June 4 campaign report identifies four concrete indicators of compromise.

• Any client-side JavaScript containing a string beginning with sk_test_ or sk_live_ confirms compromise. These are Stripe secret keys, server-side credentials that no legitimate front-end integration puts in browser-executed code.
• Direct calls to api.stripe.com originating from custom front-end JavaScript, outside of Stripe’s own embedded payment widget, are suspicious. Stripe’s client-side library never calls the customer API directly from the browser; any such call in custom JavaScript falls outside standard integration patterns.
• GTM container IDs linked to this campaign include GTM-P6KZMF63, GTM-55976FLP, GTM-MSDHV3HG, and GTM-TV4CSHVN. Any GTM container or custom tag the store’s own team did not add warrants immediate audit and removal.
• Any call to firestore.googleapis.com from front-end JavaScript on a checkout page, particularly toward paths containing payment-processor brand names, should be investigated immediately.

Runtime behavioral monitoring that watches what code does inside a browser session, including detecting when new Function() assembles a payload during a checkout flow, catches what domain-based filtering misses.

Audit Steps for Magento and Adobe Commerce Operators

For Magento and Adobe Commerce operators, the most direct starting point is a full GTM account review. Every container and custom tag should be checked against what the store’s own team added; anything unrecognized should be removed. Sansec’s eComscan scanner checks Magento and Adobe Commerce stores for injected skimmers, backdoors, and unauthorized code changes across the full codebase.

Any store with a Stripe integration should scan browser-executed JavaScript for Stripe secret keys. Finding a sk_test_ or sk_live_ prefix in front-end code confirms compromise; credentials should be rotated immediately and the Stripe dashboard audited for unexpected customer records storing card data in metadata fields.

For shoppers, the data this campaign captures covers everything used for card-not-present fraud: the full card number, CVV, expiration date, billing address, and phone number. Virtual cards with fixed spending limits, available from most major banks on request, cap the loss if a number is stolen at checkout.

The stolen cards sit in the attacker’s Stripe account, retrievable via the same API every payment-aware network policy already trusts, until Stripe locks the compromised account.