Stripe's Trusted API Infrastructure Repurposed to Deliver Card-Skimming Code and Store Stolen Data

TL;DR

On June 4, 2026, e-commerce security firm Sansec disclosed a new Magecart (web-skimming) campaign abusing Stripe’s API infrastructure. Stripe itself was not breached. The attacker repurposed the trusted domains an online store implicitly allows (api.stripe.com and googletagmanager.com) as both the delivery channel for the card-skimming payload and the storage backend for stolen data. The skimmer loads from a Google Tag Manager container, reconstructs JavaScript stored in the metadata field of a specific Stripe customer record, and runs it via new Function(). Stolen card data (number, expiry, CVV, name, address, contacts) is XOR-obfuscated, stored locally, then written into a fake customer record created in the attacker’s own Stripe account. Because the store allows Stripe domains by default, it passes CSP and network filters. The customer record dates to 2025-12-24, and a Google Firestore variant was also seen. This belongs to Pillar 01 (Verifiable Origin) code-provenance: an allowlist trusts a domain’s “identity” but does not verify the “provenance” of the code and data it carries — joining Brief 010 (a trust signal repurposed as a delivery channel).

Incident overview

• Target: Magento / Adobe Commerce checkout pages (the victims are the e-commerce stores; Stripe and Google are abused trusted infrastructure, not victims).
• Disclosure: 2026-06-04, analysis published by Sansec.
• Abused trusted infrastructure: api.stripe.com (payment processing) and googletagmanager.com (tag management) — both domains stores allow by default.
• Delivery: malicious code is embedded in a legitimate-looking GTM container; on reaching checkout it queries a Stripe API customer record (e.g. cus_TfFjAAZQNOYENR), reconstructs JavaScript from its metadata, and runs it via new Function().
• Stolen: credit card number, expiry, CVV, name, billing address, email, phone.
• Storage / exfiltration: stolen data is concatenated into a single string → XOR-obfuscated → stored locally. A separate routine, running right after page load and every minute, splits the data and creates a new customer object in the attacker’s Stripe account, storing it in metadata. After copying, it wipes the local copy to erase traces.
• The evasion core: both payload and stolen cards travel through api.stripe.com. Because the store allows that domain by default, it slips past the CSP and network filters that would catch an unknown skimmer domain.
• Variant: a version using Google Firestore instead of Stripe (project braintree-payment-app, document tracking/captcha) was also seen — naming that blends with legitimate payment / bot-defense traffic.
• Origin: the Stripe customer record holding the skimmer was created on 2025-12-24, suggesting activity from at least that date.

Chain of events

(This is an attack campaign, but the full set of victim stores has not been published, so we lay it out as a chain of events, based on Sansec’s analysis.)

• 2025-12-24: the Stripe customer record holding the skimmer is created (likely the start of activity).
• During the period: malicious code is embedded in victim stores’ GTM containers, firing on reaching checkout.
• Per purchase: the skimmer fetches customer-record metadata from the Stripe API → reconstructs and runs JavaScript → steals card data, XOR-obfuscates, stores locally.
• After page load / every minute: it splits the stolen data, creates fake customer records in the attacker’s Stripe account, and wipes the local copy.
• 2026-06-04: Sansec discloses; BleepingComputer and others report; the Firestore variant is confirmed alongside.

Technical structure of the chain

1. Parasitizing trusted domains: the attacker uses googletagmanager.com / api.stripe.com, which stores allow by default, for delivery and storage — never exposing a domain of their own.
2. Indirect code placement: the skimmer body sits in the metadata of a Stripe customer record and is reconstructed and run via new Function(). Static code inspection and domain allowlists don’t flag it as malicious.
3. Steal and stash locally: card data from checkout is stolen, XOR-obfuscated, and held locally for a moment.
4. Exfiltration over the trusted channel: stolen data is written into a fake customer record in the attacker’s Stripe account. Because the destination is api.stripe.com, it passes CSP and egress filters.
5. Trace erasure and redundancy: the local copy is wiped after sending; the Firestore variant adds delivery / storage redundancy.

Structural analysis

This belongs to Pillar 01 (Verifiable Origin), category code-provenance. The central failure primitive is that CSP / network allowlists trust a domain’s “identity” (this is Stripe; this is Google) but do not verify the “provenance” of the code and data it carries (who placed this script, and by which legitimate path). We mark identity-auth (over-reliance on a trusted domain’s identity) and data-provenance (stolen data exfiltrated over a legitimate channel) as secondary.

It is the same shape as Brief 010 (Claude Code source-leak lure malware). 010 repurposed the trust signal of the Anthropic brand and the legitimate delivery path of GitHub Releases for malware delivery. This case repurposed the infrastructure of trusted brands — Stripe / Google — for skimmer delivery and stolen-data storage. Both share the core of the verifiable-origin category: what is trusted is the issuer’s identity, not the provenance of the contents it carries. It is also adjacent to Brief 004 (Megalodon) in using a legitimate ecosystem (GitHub / a payment API) as the attack’s transport layer.

What matters is that this primitive strikes the very premise of the allowlist defense. An allowlist works by rejecting unknown domains, but as long as a trusted domain can carry arbitrary code and data, per-domain trust guarantees nothing about the correctness of the contents. That api.stripe.com is Stripe’s legitimate API, and that the metadata it carries is legitimate payment data, are separate questions.

The detection–proof gap

Skimmer analysis, IOC sharing, and victim-store notification by e-commerce security firms like Sansec are essential to containing the campaign; this Brief does not dispute that role. Users can also reduce risk with single-use virtual cards with limits.

But detection does not change “whether the browser executes code loaded from a trusted domain” or “whether data sent to a trusted domain is allowed.” Here the traffic is to api.stripe.com / googletagmanager.com, which CSP and network filters allow by default. The skimmer body is scattered across customer-record metadata and dynamically assembled via new Function(), so it is hard to catch even with static inspection. Stolen data leaves through the legitimate Stripe customer-object-creation API. What was missing is provenance verification of “is the script that runs on this checkout page one the store placed legitimately?” — a different track from domain allowlists and anomaly detection. For regulatory reporting and PCI audit, too, after a leak there is little independent trail beyond reconciling GTM history with access logs to prove “which script, by whose placement, touched the card data when.”

Pre-execution attestation verifies the code that runs at checkout not by a domain allowlist but by the provenance of who placed it, by which path, and with what content — before execution. If the proof says “this script has no legitimate store-placement provenance,” execution is blocked even when it comes from a trusted domain. A domain allowlist (“is this a known trusted source”) and pre-execution proof of code provenance (“was this content placed legitimately”) are not substitutes but complements (for the detection-vs-proof thesis, see The last layer left for cyber defense in the AI era (Lemma, 2026-05)).

Response and industry context

• Sansec: analyzed and disclosed the skimmer’s behavior, the abuse structure across both Stripe and Firestore, and the customer-record creation date (2025-12-24), giving stores visibility.
• The trusted-infrastructure side (Stripe / Google): neither company’s own systems were breached; what was abused were legitimate API and tag-management features. Shutting down attacker accounts / containers is the operators’ domain.
• Cross-industry: Magecart that repurposes trusted domains for delivery and storage exposes the limits of per-domain defenses like CSP and domain allowlists. The argument to verify the provenance of code that runs at checkout independently of the domain’s identity is gaining weight through this case and Brief 010. In the PCI DSS context, script-integrity management for payment pages is strengthening as a requirement.

Lemma’s analysis

Against the detection–proof gap exposed here (an allowlist trusts a domain’s identity but does not verify the provenance of the code and data it carries), Lemma proposes a design that verifies executed code and exchanged data — not by a domain allowlist but as the provenance of who placed it, by which path, and with what content — as an independently verifiable cryptographic proof before execution. Even when delivered from a trusted domain, if the provenance proof reports the absence of legitimate placement, execution and exfiltration are rejected in advance. For the “a domain is trusted ≠ the provenance of its contents is correct” design of the verifiable-origin category, and its reference implementation, see the verifiable-origin proof sample (GitHub). For the same shape of trust-signal repurposing, see Brief 010 (Lemma Critical Brief).

Sources

• Sansec: Magecart campaign analysis (Stripe / Firestore abuse structure, customer-record creation date, IOCs) (2026-06) — https://sansec.io/research
• BleepingComputer: “Credit card theft campaign abuses Stripe to host stolen payment info” (2026-06-04) — https://www.bleepingcomputer.com/news/security/credit-card-theft-campaign-abuses-stripe-to-host-stolen-payment-info/
• The Hacker News: “New Magecart Campaign Abuses Stripe API to Host and Exfiltrate Stolen Card Data” (2026-06) — https://thehackernews.com/

About distribution

Lemma Critical Brief is a threat intelligence brief published by Lemma. It is structured analysis of public information — not an audit, assessment, or recommendation directed at any specific organization. For decision-support use, please consult your Lemma Critical contact directly.

Discovery Call → Whitepaper → ✉️ Newsletter →

(c) 2026 FRAME00, INC. — Built for decisions that matter.