← All articles · April 29, 2026 · CheckoutProof

Magecart Explained: How Card Skimmers Hide in Your Third-Party Scripts

If you’ve heard the word “Magecart” but couldn’t explain to a colleague exactly what it is, this article fixes that. By the end you’ll understand the attack chain, why traditional defenses miss it, and why the PCI Council made client-side script monitoring mandatory in 2025.

Where the name comes from

In 2015, RiskIQ named a specific group of attackers “Magecart” — a portmanteau of “Magento” (the e-commerce platform they were targeting) and “shopping cart” (where the action happens). The name stuck.

The term has since drifted. There are now at least seven distinct Magecart “groups,” numbered by the threat-intel community based on tooling and infrastructure overlap. Some are nation-state-adjacent. Some are run by single people. They don’t all share code; they share a technique.

The technique is what matters: inject malicious JavaScript into a payment page so that the browser sends a copy of the card number to the attacker as the customer types it. Everything else is variation.

How the attack actually works

The mental model most people have is “the attacker hacked your website.” Sometimes that’s true. Usually it’s not. The more common model is:

1. Your store loads a JavaScript file from a third party — your analytics provider, a chat widget, a tag manager, a recommendation engine, a pixel.
2. The attacker compromises that third party — not you. They modify the JS file to add a few lines of skimmer code at the end.
3. Your store loads the modified file. The skimmer code now runs on every checkout page render.
4. The skimmer attaches event listeners to the card-input fields (or hooks the form’s submit) and reads the card number, expiration, CVV, and customer name as the customer enters them.
5. The skimmer POSTs those values to an attacker-controlled domain — usually one that looks like a typo of a real CDN (anylytics.com, g-stat1cs.com, etc.).
6. The customer’s transaction completes normally. Nobody notices anything because nothing visibly broke.

The breach lives entirely in the customer’s browser. Your server logs show nothing unusual. Your firewall has no signature for it. Your AV product can’t see it. The fraud appears weeks later when stolen cards start hitting CNP fraud detection at the issuing banks.

Three incidents that made it real

British Airways (2018) — Magecart Group 6 compromised a JavaScript file that British Airways’ booking site loaded. The skimmer captured payment-card data for ~380,000 transactions over two weeks. The UK’s Information Commissioner’s Office initially fined BA £183 million; the final settlement was £20 million. BA’s own systems were not breached. A single third-party-hosted JavaScript file was.

Ticketmaster (2018) — Same group, similar pattern. The skimmer was injected into a chat-widget JavaScript file that Ticketmaster loaded from a third-party vendor (Inbenta). The vendor was breached; Ticketmaster’s site was not. Roughly 40,000 customers’ card data was stolen before anyone noticed.

CosmicSting (2024) — A specific attack chain combining CVE-2024-34102 (an XML external entity vulnerability in Adobe Commerce / Magento) and CVE-2024-2961 (a glibc memory corruption issue). Researchers at Sansec reported in October 2024 that the chain hit roughly 75% of all Adobe Commerce stores at peak — over 4,200 active skimmers identified across hosted Magento installations, persisting for weeks because the vulnerability allowed attackers to inject directly into the merchant’s own backend.

MirrorMask (April 2025) — A reverse-proxy-based campaign that spoofed Stripe’s own JavaScript. The attackers stood up domains that looked like Stripe’s CDN (js.str1pe.com-style typosquats) and tricked compromised stores into loading the malicious version of stripe.js. The skimmer was nearly indistinguishable from real Stripe behavior. Researchers found it embedded in dozens of mid-market merchants before publication.

SessionReaper (CVE-2025-54236, August 2025) — Another Magento vulnerability. Sansec’s data showed only 38% of stores patched within two months of disclosure. Skimmers that exploited it persisted on merchant servers for the rest of 2025.

The common thread isn’t the technical exploit. It’s that the merchant didn’t know what JavaScript was running on their checkout. None of these breaches would have lasted long enough to monetize if the merchant had been monitoring script integrity.

Why traditional defenses don’t help

Merchants ask: “I have a WAF and Cloudflare in front of my site. Doesn’t that stop this?”

It doesn’t, and here’s why.

WAFs inspect requests to your origin. Magecart attacks don’t touch your origin. The compromised script is loaded from a third party’s CDN. The card-number exfiltration POST goes to the attacker’s domain. Your WAF never sees either.

CDNs and DDoS protection inspect traffic patterns. Magecart is a low-volume, low-throughput attack. One POST per transaction, to a domain that doesn’t look like an attacker. There’s no flood to detect.

Antivirus and EDR run on servers and laptops. The malicious code never lands on a server or laptop you control. It runs in the customer’s browser, invoked by HTML you served and JS your vendor served.

Server-side intrusion detection sees nothing. Your access logs show normal traffic. Your application logs show normal checkout sessions. The compromise lives one layer above your stack.

Even client-side defenses miss it if they aren’t designed for this. A standard CSP without script-src restrictions is basically advisory. A CSP with restrictions but no report-uri tells you nothing when something almost gets blocked. Generic browser security headers don’t catch the case where your authorized third-party script gets compromised at the source.

The defenses that actually work are:

• Subresource Integrity (SRI) on every external script you can pin a hash to — the browser refuses to run a tampered script. Doesn’t help with scripts that change frequently, but pins the ones that don’t.
• Content Security Policy with script-src allowlist and report-to reporting — detects when something tries to load from a domain you didn’t authorize, and tells you about it.
• Continuous monitoring of your script inventory — when a vendor suddenly starts loading a new script, or an existing script’s hash changes unexpectedly, you find out within hours rather than months.
• A short list of authorized third-party scripts — the most effective defense is fewer scripts. Every script on your checkout page is a potential supply-chain entry point. Half the scripts on a typical merchant’s checkout were installed for an experiment that ended six months ago.

The regulatory response: PCI v4.0 6.4.3 and 11.6.1

The PCI Security Standards Council watched the cumulative damage from Magecart-style breaches across 2017–2022 and concluded that script-side monitoring needed to be a hard requirement. PCI DSS v4.0, finalized in March 2022, added two:

• Requirement 6.4.3 — Maintain an inventory of all scripts running on payment pages, with a written justification and authorization for each, and a method to detect tampering.
• Requirement 11.6.1 — Detect and alert on unauthorized changes to payment pages, at least weekly, automatically.

Both became mandatory and assessable on March 31, 2025. Every merchant attesting to PCI compliance after that date must have an answer for both.

The rules don’t mandate a specific tool. They mandate that you can demonstrate: (1) you know what’s running on your checkout, (2) you authorized it, and (3) you’d notice if it changed. Read our plain-English guide to 6.4.3 for the practical checklist.

What you should actually do

If you’re a small or mid-market merchant, here’s the bare minimum:

This week:

1. Run a free script scan on your checkout page. Get a list of every JavaScript that loads. You will be surprised by how long the list is.
2. For each script, ask “do we still need this?” Delete the ones you don’t.

This month:

3. Add SRI hashes to every external script that loads from a stable URL.
4. Add a CSP header to your checkout page with script-src restricted to the specific domains you actually need.
5. Set up report-to so CSP violations land somewhere you’ll see them.

Ongoing:

6. Run a weekly script inventory scan. Diff against last week’s. Investigate anything that changed.
7. When a vendor pushes a new version of their JS, treat it as a change requiring re-authorization. Re-pin SRI. Update your inventory document.

That’s the whole defense. None of it is exotic. The reason Magecart is so persistent is that nobody is doing it.

What this looks like with CheckoutProof

The free scanner does steps 1 and 4 in one click and emails you a one-page PDF you can hand to your acquirer. The paid product runs the weekly scan in step 6, ingests the CSP reports from step 5, and produces audit-ready evidence for PCI 6.4.3 and 11.6.1 at attestation time.

You don’t have to use ours. You do have to know what’s running on your checkout. The next Magecart variant doesn’t care which side of that line you’re on.

Run a free scan on your checkout page now. You’ll know within 30 seconds whether you’re already exposed.

Run a free PCI 6.4.3 scan of your checkout page. Get the script inventory and a one-page PDF report. Try it now →