🤚 The Open-Palm Transaction

A new Magecart credit card theft campaign has achieved something genuinely elegant in the annals of cybercrime: it is using Stripe’s own API infrastructure to both deliver the malware and exfiltrate the stolen payment data. Security researchers at Sansec discovered that attackers are hijacking Google Tag Manager containers on Magento and Adobe Commerce checkout pages to inject a skimmer that stores stolen card numbers inside fake Stripe customer objects — using Stripe’s metadata fields as a free, trusted, enterprise-grade data warehouse for fraud.

The payload retrieves its JavaScript from a Stripe customer record (specifically cus_TfFjAAZQNOYENR, if you’d like to report it), executes on the checkout page, and captures everything: card numbers, expiration dates, CVV codes, names, billing addresses, emails, and phone numbers. The stolen data is XOR-encrypted, stored locally, and then uploaded by creating new fake Stripe customer objects with the stolen information stuffed into metadata fields.

The operation has been running since at least December 24, 2025 — because nothing says “Merry Christmas” like a supply chain compromise that weaponizes your own payment processor.

👐 The Two-Handed Heist

Here is the part that elevates this from ordinary Magecart skimming to something approaching art: both the payload delivery and the data exfiltration happen through api.stripe.com. And because every e-commerce store on earth already whitelists Stripe’s domain in their Content Security Policy, the skimmer passes every security check without triggering a single alert.

Read that again. The malware is hosted on Stripe. The stolen data is sent to Stripe. The entire attack lives inside a domain that your security team has explicitly told your browser to trust. Your CSP rules — the ones your security engineer spent two weeks configuring and testing — are actively helping the attackers by ensuring their traffic is never blocked.

• Malware delivery: Via Stripe customer record metadata
• Data exfiltration: Via Stripe customer record creation
• CSP bypass: Automatic, because you already trust api.stripe.com
• Local evidence: Wiped after exfiltration every 60 seconds
• Initial access: Compromised Google Tag Manager containers

A variant of the campaign uses Google Firestore instead of Stripe for data storage, because when you’ve already turned one trusted platform into a crime scene, why not diversify your portfolio?

🌿 The Gentle Awakening

Content Security Policy was supposed to be the grown-up in the room. The entire premise of CSP is: “only load resources from domains we trust.” It was the security community’s answer to cross-site scripting, rogue scripts, and malicious injections. It was, for a brief and beautiful moment, effective.

Then someone realized that the most trusted domain on any e-commerce checkout page is the payment processor itself, and that Stripe’s API will happily store arbitrary data in customer metadata fields without asking what that data is or why it looks suspiciously like 16 digits and a CVV. The trust model didn’t fail. It was inverted. The thing you trusted most became the thing you should have trusted least.

This is the fundamental paradox of modern web security: every tool designed to create trust also creates a blind spot. Whitelisting is protection until someone lives inside the whitelist. Certificate pinning is security until the attacker has a valid certificate. And Stripe is your payment processor until it’s also your attacker’s data warehouse.

👑 The Gold-Leaf Reckoning

For every e-commerce operator running Magento or Adobe Commerce: audit your Google Tag Manager containers immediately. The initial access vector is compromised GTM accounts, and if your GTM container has scripts you didn’t put there, your checkout page is someone else’s revenue stream.

For Stripe: your platform is being used as malware infrastructure. The customer metadata fields that make your API flexible and developer-friendly are being weaponized as a dead drop for stolen payment data. The same “it just works” philosophy that made Stripe the default payment processor for the internet has made it the default exfiltration channel for criminals who appreciate good developer ergonomics.

For the security community: CSP-as-defense needs a fundamental rethink when the trusted domains themselves become attack infrastructure. You cannot whitelist your way out of a world where the trusted party is compromised. The answer is not more whitelisting. The answer is behavioral monitoring of what trusted domains are actually doing — and right now, Stripe’s API is doing things that would make your fraud team cry.

“The attackers stored stolen credit cards inside Stripe’s own customer records. The payment processor became the getaway car. The CSP policy held the door open. If this were a heist movie, the critics would call it unrealistic.” — The Slap of Wisdom Payments Integrity Desk, currently reviewing its own checkout page with a flashlight and a sense of dread