Magecart is not a gang. It is not a piece of software either, and it is not a single attack. It is a label that researchers attached to one method of stealing card details, and then kept using as the number of people employing that method grew.
That is worth settling early, because coverage tends to say “Magecart struck again” as though one organisation were responsible. Dozens of separate crews use the technique. Some are careful, well resourced and patient. Some are working from a tutorial and a rented server.
Where the name came from
The word is a portmanteau of Magento, the e-commerce platform, and shopping cart. Researchers began using it around 2016 for a cluster of attacks that injected card-stealing JavaScript into Magento checkout pages, and it stuck.
It then outgrew its own definition. Attacks called Magecart today hit shops built on WooCommerce, on hosted platforms, on bespoke checkouts, and on stacks with no Magento anywhere in them. Some researchers prefer web skimming or formjacking for that reason, and they are more accurate. Magecart is simply the term most people recognise.
Not one group but many
From 2018 onwards, researchers began dividing the activity into numbered groups, separated by the code they used, the infrastructure they registered and the way they chose targets. The numbering has grown since. The useful part is not the numbers but the fact that the groups behave in three quite different ways.
- Some go wide. They scan the internet for shops running an unpatched platform or a vulnerable extension, and inject the same skimmer into thousands of them. Most of those sites take very few orders. It does not matter, because the scanning is automated and the cost per site is close to nothing.
- Some go narrow. They pick one high-traffic merchant, study how its checkout is built, and write a skimmer that matches that specific page, sometimes styled to survive a casual code review. Then they wait, quietly, for as long as they can.
- Some never touch the target at all. They compromise a supplier whose script is loaded by hundreds of merchants, and let the supply chain distribute the skimmer for them.
That third pattern is what turns Magecart from a hygiene problem into a structural one. A merchant can patch everything it owns, enforce multi-factor authentication on every account, and still serve a skimmer to its customers, because the malicious code arrived inside a script it had deliberately chosen to load.
Two cases that set the pattern
Ticketmaster UK, 2018. A skimmer reached the payment pages through a third-party chat widget supplied by another company. The widget had no business being on a page where card numbers were typed, and when the supplier was compromised the skimmer came with it. This is the supply chain route in its clearest form.
British Airways, 2018. Payment details for hundreds of thousands of customers were captured over roughly two weeks by a script injected into the airline’s website and app. The Information Commissioner’s Office fined the airline £20 million in 2020, at the time its largest penalty, and was explicit that the failure was one of ordinary security hygiene rather than an exotic attack. This is the targeted route.
Both were disclosed in the same year, both were called Magecart, and they had almost nothing in common in terms of how the attackers got in. That is the point.
Why the technique works
A skimmer reads the card fields in the customer’s browser, as they are typed, and then lets the real payment proceed. Nothing fails. The merchant’s servers never see anything unusual, because the theft happens before the form is submitted and therefore before any encryption or tokenisation applies.
This is the detail that catches businesses out. A payment provider that tokenises card data protects the data once it reaches the provider. A TLS certificate protects the data in transit. Neither does anything about code running on the page that reads the keystrokes first.
Why it has not gone away
The economics are unusually favourable. Injecting a script costs almost nothing. Card data sells in bulk. Detection is slow, because a working skimmer produces no errors, no failed payments and no complaints. The first sign is usually a card scheme noticing that a cluster of fraudulent transactions share one merchant in their recent history, and working backwards.
Meanwhile the attack surface keeps growing. A typical checkout page loads code from analytics, tag management, chat, reviews, personalisation, consent management and advertising. Each of those is a supplier, and each supplier is a way in.
What has changed
The Payment Card Industry Data Security Standard addressed this directly in version 4.0. Two requirements, mandatory since 31 March 2025 for merchants handling card data, say in effect: know every script on your payment page and confirm it is authorised, and monitor the page for unauthorised change. Those two sentences are a fair summary of the defence whether or not the standard applies to you.
The browser has caught up too. A Content Security Policy lets a page declare which domains it may send data to, so a skimmer trying to reach a rogue host is blocked and the attempt reported. Subresource Integrity lets a page pin the exact hash of a third-party file, so a supplier’s compromised script simply refuses to run.
The most effective change is more mundane. If the card fields live in an iframe served by the payment provider, rather than in your own page, a skimmer running on your page cannot read them at all. For most small merchants that is a configuration choice rather than a project, and it removes the exposure rather than monitoring it.
The short version
Magecart is a name for a method, not for a group. It covers everything from automated mass injection into neglected shops to patient, tailored attacks on large merchants, and increasingly to compromises of the suppliers whose code those merchants load.
What the variants share is the moment of theft: in the browser, on a genuine page, before anything encrypts or tokenises the data, and without interrupting the payment. Which is why the defence is not a product but a discipline: knowing exactly what runs on your payment page, and noticing when that changes.