What is Magecart?
Where the name came from, the three routes attackers actually use, and why the average incident runs for months without anything visibly breaking.
TL;DR
Magecart
WHAT IT IS
An umbrella term for cybercriminal groups that inject malicious JavaScript into checkout pages to steal card data as customers type it.
WHERE THE NAME CAME FROM
Early campaigns targeting Magento stores. It now refers loosely to the whole category rather than one group.
WHY IT HIDES
The card is read in the browser and posted straight to the attacker. Your server logs record a successful checkout, because the checkout genuinely succeeded.
Short on time? The most common entry route is a compromised third party you already approved.
What is Magecart?
Magecart is the collective name for a set of cybercriminal groups that inject malicious JavaScript into ecommerce checkout pages in order to steal payment card details as customers enter them. The name comes from early campaigns against Magento storefronts and has since become shorthand for the entire technique, which is also called web skimming, e-skimming or formjacking. There is no single Magecart organisation. Researchers track numbered groups with distinct tooling and infrastructure, and the skill level ranges from operators buying a kit to groups capable of compromising a major service provider and reaching thousands of sites through it.
40 SESSIONS ON ONE CHECKOUT
Sampled
Skimmer fired
Not observed
A targeted skimmer fires for a slice of traffic: one country, one card BIN, one hour. Sampling is the norm in this category, commonly 10% of sessions and sometimes as low as 1%. That is a coin flip against an attack designed to be rare.
The three routes onto your page
1
Compromise a third party
Breach a vendor whose script you already load and change what it does. Your allowlist passes, your CSP passes, and the origin is one you approved. This is the most common route and the hardest to see.
2
Compromise the tag manager
A tag container exists to inject arbitrary JavaScript. An attacker with access does not need your codebase, your repository or your deploy pipeline.
3
Exploit the site directly
A vulnerable plugin, an outdated platform, or an exposed admin account, used to add a script to the page. This is the classic Magento route the name came from.
Why it stays hidden for months
Nothing breaks. The customer fills in the form, the payment succeeds, the order ships, and the card is copied on the way through. There is no outage, no error-rate change, no failed transaction, and no unusual request arriving at your infrastructure, because the stolen data is posted from the browser directly to a server the attacker controls.
The first signal is typically external: an acquirer or card brand reporting a common point of purchase across fraudulent cards. By then the exposure window is already large.
Detection has to happen where the code runs, which is the browser.
Built to be rare
Skimmer payloads are written to fire selectively, which is what makes periodic scanning unreliable against them. Common conditions: only on a checkout URL, only when a card field is present, only for certain card BIN ranges, only outside the operator's working hours, never when the browser looks automated, and never twice for the same visitor.
only on a checkout URL
only when a card field is present
only for certain card BIN ranges
only outside the operator's working hours
never when the browser looks automated
never twice for the same visitor
A crawler arriving from a datacentre IP with no session and no cart is precisely the visitor the payload is written to ignore.
Two incidents that show the pattern
British Airways, 2018. Attackers changed a JavaScript library that the airline's booking pages already loaded, adding a few lines written specifically for that site. Card details entered during booking were copied to a server the attackers controlled, under a name chosen to look like part of the airline's own infrastructure. The script ran for about two weeks before it was found, and the UK Information Commissioner's Office later fined the airline ÂŁ20 million.
The Polyfill supply-chain attack, 2024. A free polyfill service used by more than 100,000 websites changed hands, and the new owner began serving altered code from the same address. The payload was selective: it fired for some mobile visitors, at some times, and stayed quiet for site administrators. Every site that loaded it had approved the script long before, so nothing about the origin had changed.
Both follow the same shape. The code arrived through a source the site already trusted, it was written to run only where it was least likely to be watched, and nothing on the server side looked unusual.
What actually detects it
A script that is not in your inventory executing on the payment page
An approved script whose payload hash changed, which is the compromised-vendor case
A script reading payment form fields when that is not its purpose
A new outbound destination from a script that previously only talked to its own domain
A security header quietly loosened to permit something new
Sources and methodology
PCI DSS requirement text is quoted from PCI DSS v4.0.1 (June 2024), published by the PCI Security Standards Council, which is the current version at the time of writing. Requirements 6.4.3 and 11.6.1 became mandatory on 31 March 2025. Where we describe a competitor, we describe publicly available information and say so when something should be verified with the vendor. We publish this product and that is a bias worth knowing about while you read.
ASK AN AI
Don’t just take our word for it
Ask your assistant what to look for in a tool for PCI DSS 6.4.3 and 11.6.1.
Frequently asked questions
Yes to both, which is why the term is confusing. It began as a name for specific groups targeting Magento stores and is now used loosely for the whole category of browser-based card skimming. Researchers track numbered groups with distinct tooling, but there is no single Magecart organisation.
No. A web application firewall inspects traffic arriving at your application. A skimmer reads the card in the browser and posts it from the browser to the attacker, so that traffic never reaches your infrastructure and there is nothing to inspect.
Partly, and it is worth running one. A CSP restricts which origins may load scripts and where data may be sent, which raises the cost of the attack. It does not help when malicious code arrives from an origin you already allowed, which is the most common route.
Typically far too long: weeks to months is common, because nothing visibly breaks. Many merchants learn about it from an acquirer raising a common point of purchase rather than from their own monitoring.
No, not any more. The name is historical. The technique works against any checkout that loads third-party JavaScript, which is nearly all of them, on every major ecommerce platform.
Usually through resale rather than direct use. Harvested card data is sold in bulk on criminal marketplaces, often batched by issuing bank and card type, which is also why BIN-range filtering appears in skimmer code.
Yes, by a different route. A script cannot read inside the provider's cross-origin iframe, and it can overlay a fake form on top of it, capture keystrokes before the iframe receives them, or replace the iframe's source. The page around the iframe is where that happens.
Treat it as an incident rather than a cleanup task. Preserve the payload as evidence before removing it, because it tells you what was collected and where it went. Determine the exposure window from your records, then follow your incident response and notification obligations.
Yes, substantially. Requirements 6.4.3 and 11.6.1 were introduced in PCI DSS v4.0 and made mandatory in March 2025 specifically because the card brands view browser-based skimming as an ongoing and growing problem that existing controls did not address.
Yes. The tooling, hosting and evasion techniques have evolved, and the underlying economics have not changed: checkout pages load third-party code, third parties get compromised, and card data has resale value.
Related articles
Attacks
What is web skimming? How card data leaves the browser
The technique, the exfiltration methods, and why your server logs show a successful checkout.
Attacks
What is formjacking? The mechanism, explained
How a script hijacks a form, the two main implementations, and what detects each one.
Attacks
Shadow code: the scripts nobody approved
Code executing on your pages that no one on your team chose, and how it gets there.
Attacks
Homoglyph attacks: when a domain is not the domain
Characters that render identically, and why they work so well against script allowlists.
See every script on your own checkout.
Install the tag, mark your payment pages, and watch the inventory fill in. Free forever on 1,000 page views a month, no credit card.
Free forever plan. No credit card.