In This Blog:
- What is a Magecart attack
- How Magecart attacks work
- How to prevent Magecart attacks
- Why Magecart attacks are hard to detect
- Biggest Magecart attacks in history
“I was recently notified of a data breach on your store and my credit card has been abused.”
This is a customer support nightmare. Not only that: your fraud and finance teams are also getting alerts from card issuers and questions from payment providers.
Magecart isn’t about faking login or payment pages. It’s about the abuse of your real login and checkout pages that customers trust.
That’s Magecart: it’s what happens when your login and checkout become the weakest link in your security controls. Even if your servers, WAF and PCI controls are solid, a few lines of malicious JavaScript in the browser can skim card data and PII for weeks before anyone notices.
This guide shows what Magecart is, how it works, why it is hard to detect, tips for provincial, and tools for Magecart prevention.
What is a Magecart attack?
A Magecart attack is a browser-based web skimming attack. Malicious JavaScript is injected on an e-commerce site with one purpose: to steal payment card data.
It’s something you don’t wish on yourself or your customers. It’s a nightmare for online stores because it abuses the trust of your customers. It causes great damage to online business: financial losses, chargebacks, regulatory fines and serious reputational damage.
Your WAF and server-side security stack won’t see any of this. The attack lives entirely in the user’s browser, in a code environment your backend monitoring never touches. Even other PCI DSS related controls like encryption or tokenization mean nothing if the attacker steals the card data before those defenses are even in play. Transactions on your side just keep going through as if nothing is wrong. From your perspective, it looks like business as usual. But in the meantime, data is quietly exfiltrated from your customer’s browser to the attacker’s servers.
Magecart is A Type of Web Skimming
Magecart is a form of web skimming (or e-skimming). Web skimming is the online version of credit card skimming from ATMs: keystrokes or inputs are copied by hidden devices and later used to spend money elsewhere. When attackers add their malicious JavaScript to an online store, it opens up a lot of opportunities for them. They can see what a user types into payment or login forms and secretly exfiltrate this data to their own systems.
How the term “Magecart” has evolved
Around 2015-2016, security researchers started reporting that Magento-based online stores were being targeted by online card skimming attacks. Typically, JavaScript was injected into checkout pages to steal and exfiltrate payment data and PII. Hence: ‘Magecart’ - ‘Mage’ from Magento and ‘cart’ - short for shopping cart.
Over time, Magecart attacks spread to other platforms and custom e-commerce setups. Any platform with client-side JavaScript and third-party scripts was vulnerable, not just Magento.
From Magento card skimming to Magecart-style attacks everywhere
Magecart evolved into an attack style: a label for digital skimming, formjacking, e-skimming, online card skimming and it has become a major threat to online retail platforms.
Magecart is less a nickname for a specific group and more an umbrella label for an ecosystem of digital skimming groups and techniques. Broadly speaking, they use the same attack vector but rely on different infrastructure and tooling.
How Magecart attacks work
The idea seems simple: copy form data and exfiltrate them to a compromised endpoint. How hard can it be? In reality, these attacks are more subtle and sophisticated. At every moment, the online store needs to behave as expected: no errors, no timeouts.
For the digital skimming to be successful, neither your monitoring systems nor your customers must notice anything out of the ordinary.
Here’s how a typical Magecart attack unfolds in the browser.
1. Injecting malicious JavaScript into the site
First, the attacker needs a way to run their own JavaScript in the user’s browser, because that is where the attack takes place. They look for vulnerabilities such as outdated or misconfigured plugins or CMS components, or neglected third-party scripts such as a plugin, CDN files, tag manager and so on.
This weak point becomes the attack vector: the attacker adds a couple of lines of their malicious JavaScript to an existing production file or third-party script. The change is tiny, often mixed in with legitimate code, so nothing stands out during a security review.
2. Reading payment and form data
Once that is done, the malicious JavaScript accesses the DOM and reads the data the user entered in the form. JavaScript accessing and changing the DOM is normal behavior in modern web development. It’s how JavaScript makes pages dynamic without reloading the full HTML-document. Many frameworks like React or Svelte rely on the fact that JavaScript can manipulate the DOM.
The digital skimmer now focuses on specific fields in the payment or login form: card number, expiry date, CVV, name, address and so on. It copies these values without changing the form or the user flow in any visible way.
3. Exfiltrating the data to the attacker’s server
Once the data is captured, the next step is to transfer it undetected to a server controlled by the attacker. Most of the time, the trigger for the exfiltration is the user clicking the ‘pay’/’submit’ button. At that moment, the script assembles the payload (raw or encoded) with card details, PII, and often details for context such as timestamps or URLs.
Typical exfiltration techniques include ‘fetch’, ‘XMLHttpRequest for old code, hidden image requests and navigator.sendBeacon(). TLS/HTTPS won’t stop the exfiltration because it looks like a legitimate https-request, with a very small payload. Attackers often use domains that look very similar to the legitimate hostnames used by online stores, CDNs or analytics so they don’t raise suspicion. If the exfiltration request fails, the code simply catches the error and will not run. But the legitimate transaction will go through.
4. Keeping the store running and fulfillment firing
For the Magecart attack to be effective, transactions must keep flowing. The skimmer exfiltrates a copy of the data, but the payment form is also submitted to your backend and payment gateway. Orders are created, payments are authorized and your fulfillment systems get to work.
How Attackers Gain Access to Web Scripts for Magecart Attacks
Attackers are scanning for weak spots in your web stack: places where scripts can be edited and skimming code can slip in. To defend your site and build an effective threat model, you need to focus on some common entry points for Magecart attacks.
1. Magecart through Plugins, CMS, or e-commerce platform code
Your own CMS or e-commerce platform is a direct attack surface. Platforms such as Magento, WooCommerce, Shopify-apps and custom checkout-code need regular scrutiny. Typical weak points are outdated plugins and extensions, or insecure edits to templates or JavaScript files. Admin-accounts need extra protection: if an attacker can log in as administrator, script changes are easy.
If your online store is running an outdated payment or tracking-plugin in Magento or WooCommerce, digital skimming is only one step away. If attackers succeed in modifying the plugin files or abuse an admin account, they only need to edit one single JavaScript-file on the checkout page to add their skimmer.
2. Magecart through the third-party code supply chain
This includes any entry via <script src> or a tag manager: CDN-libraries, A/B testing or analytics for your marketing team, chat/support widget for customer support and so on. These scripts are managed and hosted by external vendors or injected via tag managers that can run code on most pages. It only takes one compromised third-party script or abused tag manager account to spread skimmer code to all sites and pages where this code is used.
Sometimes a Google Tag Manager (GTM)-account or external chat widget has code that loads on the entire site (including checkout pages) even if they serve no functionality on those pages. If GTM is taken over and an extra tag with skimmer JavaScript code is added, every checkout form on every site that uses the container is now running Magecart code.
Why Magecart attacks are hard to detect
Now that we've seen how a Magecart attack works in the browser, it’s fair to ask: Why don’t traditional defenses catch this? We have WAF rules, SIEM dashboards and PCI controls. Yet these security layers still have a blind spot for client-side, browser-based attacks like Magecart.
1. WAF, SIEM and transaction data misses magecart attacks
Most web security tools are designed to protect server-side activity or monitor company infrastructure, not the browser of users. A WAF inspects traffic to your applications, but it doesn’t see what the browser sends directly to other domains. A SIEM shows server and infrastructure logs, but it doesn’t record extra outbound calls from the browser to malicious endpoints.
Analyzing transaction data for fraud won’t surface evidence of a Magecart attack because the legitimate purchase flow still completes normally. The skimmer copies the card details in the browser while the backend sees a clean, authorized transaction with no anomalies.
Skilled attackers can intercept sensitive values at the DOM level before they are ever sent to your servers, effectively muting your alert systems.
2. No Third-Party script visibility increases Magecart risk
Full visibility into third-party scripts is a huge challenge. What scripts are running? Are they allowed to run on a checkout form or login page? Who’s keeping track of their behavior and changes over time? All very basic questions that many organizations struggle with when nobody fully owns the client-side supply chain.
Web developers have limited control over these scripts, because they are managed and hosted by external vendors. When ownership changes or staff is laid off, third-party scripts or JavaScript libraries may no longer be updated and a vulnerability in any of those third-party scripts can become a security risk.
This is precisely the entry point Magecart attacks exploit. Compromise one widely used third-party script or library, and you can turn it into a large-scale supply chain attack across every site that uses it.
3. A client-side problem needs client-side defense
This is the core issue with Magecart: most businesses have no real visibility into what happens in the browser. Server-side security dashboards don’t show what domains the browser is sending requests to during checkout, even when those are cross-origin calls (CORS).
They don’t alert when a new outbound domain shows up on a payment form. And they don’t send a warning on a Content Security Policy violation (connect-src) when a script is trying to exfiltrate data to an unexpected endpoint.
4. Fraud is only discovered later, much later
One of the most damaging aspects of a Magecart attack is that it rarely gets detected by the organization that was actually breached.In most cases, the first signs of trouble come from banks, card issuers, or customers. By the time these external reports surface, the skimmer has already harvested a significant volume of cardholder data.
How to prevent Magecart attacks
The core principles of Magecart prevention are straightforward: keep your checkout flow as clean and minimal as possible, keep control of scripts that run there and add browser-side controls with continuous 24/7 monitoring. The following logical steps will help you to implement prevention measures to reduce your exposure to Magecart.
1. Only run necessary scripts on login and checkout
For login and checkout, every extra script adds risk. These pages should load only basic UX and what is strictly necessary for authentication and payment. Without hesitation, remove marketing, analytics, chat widgets and so on from login and checkout.
Preferably, isolate checkout and use a minimalistic template or even a separate subdomain with only necessary third-party input. In doing so, you limit your attack surface and the opportunities for Magecart code to hide its tracks. Also, you’ll have a much easier time to clean up if something goes wrong.
2. Use cside for third-party script governance
Create a script inventory to get a clear view of what scripts run where, and what they actually do. Sensitive pages including login and checkout should only serve third-party scripts that have been approved with a justification.
Finally, define a change management process to specify who is allowed to modify scripts and tag manager containers. You can also require previews and approval before changes go live. In parallel, apply strict vendor governance and make script security and incident handling part of contracts and onboarding with external providers.
A third-party script governance tool can automate these elements instantly with a dashboard that matches each script to a vendor, and automatically generates descriptions of what each script is doing.
3. Use browser controls: CSP and SRI
A Content Security Policy (CSP) helps you define where scripts are allowed to load from (`script-src`) and where the browser is allowed to send data (`connect-src`).
`script-src` should be restricted to trusted domains and `connect-src` should allow only the endpoints needed for checkout rather than allowing every destination.
Enabling a CSP also helps reporting on policy violations, especially on login and checkout. Unexpected script injection and exfiltration attempts will be revealed. For static third-party libraries, use Subresource Integrity (SRI) to harden integrity but treat it as one layer in your defense, not as the silver bullet solution.
4. Use cside to for Magecart monitoring
With Magecart, you need eyes in the browser. Continuous, 24/7 automated client-side monitoring will reveal what scripts are running and suspicious behavior that signals magecart activity. A Magecart prevention tool maps all the scripts on your site and uses an AI-assisted engine to detect red flags from a variety of data points.
cside helps merchants identify and stop:
- Third-party JavaScript supply-chain attacks
- Malicious or tampered third-party scripts
- Misconfigured scripts leaking sensitive data
- Magecart, e-skimming, formjacking, and related skimmers
cside is validated for PCI DSS 4.0.1 client-side requirements and is used by compliance teams to prevent GDPR, CCPA, and other privacy violations caused by risky third-party scripts.
Magecart readiness quick self-assessment
Are you ready to ward off Magecart-style attacks? Yes/no
- Our checkout and login pages load only scripts where we know the purpose and expected behavior
- We have an up-to-date list of all scripts, first- and third-party, that run on our checkout page.
- Marketing, analytics, A/B testing and chat widgets are monitored to ensure they aren’t collecting more data than necessary
- Changes to ‘trusted’ scripts such as tag manager containers …
- We are verifying script integrity through a client-side security tool or another mechanism (such as Sub Resource Integrity)
- We have client-side monitoring shows which where data collected by third-party scripts is being sent to
- We have a mechanism in place to block scripts that have publicly identified as compromised
Biggest Magecart attacks in recent history
Our 2025 Client-side threat report identified 72,000+ websites impacted by client side attacks. Those attacks follow the same pattern as the biggest Magecart attacks in recent history: a few lines of malicious JavaScript compromises millions of users before anyone notices. Below is a quick summary of the most notable cases.
- Ticketmaster (2018) – Compromised Chatbot ScriptAttackers injected skimming code into a third-party chatbot hosted by Inbenta Technologies. Every page load executed the malicious script, exposing payment and personal data for roughly 9.4 million customers over four months. The incident led to regulatory fines and class-action settlements.
- British Airways (2018) – 22 Lines of Malicious JavaScriptAttackers gained access using compromised third-party credentials and inserted just 22 lines of skimmer code into a library used on BA’s payment page. Data was exfiltrated to a look-alike domain (“baways.com”), affecting about 400,000 customers. BA faced tens of millions in GDPR fines and years of litigation.
- Newegg (2019) – Injected Script on Checkout Page Attackers obtained write access to Newegg’s payment server and added a small skimmer to the checkout button. When customers submitted payment, card data was sent to a fake analytics domain (“neweggstats.com”), compromising card numbers, CVVs, and PII for over a month before detection.
FAQ
How do I know if my site has a Magecart or e-skimming infection?
Magecart attacks are hard to detect because the checkout still works normally and server-side tools see nothing unusual. The only reliable method is client-side monitoring with a tool like cside that inspects scripts running in the browser and flags suspicious code changes or outbound data transfers.
Can Magecart attacks happen even if I’m using a payment processor like Stripe or PayPal?
Yes. If your checkout fields are hosted on your own website (even when using a third-party payment processor) third-party scripts on your page may still access what users type into those fields. If your site fully redirects customers to a payment provider’s domain (e.g., checkout.stripe.com), Magecart can’t skim card data there. However, other sensitive information on your site like login credentials or KYC data, or account details can still be scraped if malicious scripts are present.
Can a Magecart attack happen if I tokenize or encrypt credit card data?
Yes. Tokenization and encryption only occur after the customer submits their payment, but Magecart steals the data as the user types. Even fully tokenized or encrypted workflows remain vulnerable to skimming if malicious scripts are running on the page.
