eSkimming attacks (often referred to as Magecart attacks) are routinely treated as isolated incidents: discovered, removed, and closed. This report challenges that assumption. Based on a year-long longitudinal study of 550 previously compromised e-commerce websites across 68 countries, our findings show that discovery does not equal recovery. eSkimming persistence is not the exception; it is the norm.

  • 18% of previously compromised sites remain actively infected one year after initial discovery.
  • Among those still-infected sites, 57% are not running the original skimmer, but a new or evolved attack path.
  • 16% of sites that were under attack a year ago in our sample have since gone offline or become unreachable.
  • Attackers pivot between first- and third-party scripts so that each round of remediation only pushes the attack somewhere else on the page.
  • In our sample, at least one-third of the attacks active today operate from first-party scripts — a trusted blind spot for many traditional security controls.

Taken together, these findings show that eSkimming is a long-lived, shape-shifting problem rather than a one-time incident. Attacks linger on a significant share of previously compromised sites, often returning in new forms and shifting between third- and first-party scripts that many traditional controls implicitly trust. 

Some of the sites that were under attack a year ago have since gone offline; while we can’t say those shutdowns were caused by eSkimming, the pattern should be a clear red flag for any business that leaves client-side attacks unresolved. 

The data makes the conclusion unavoidable: without continuous client-side monitoring, attackers are free to adapt, persist, and re-enter, turning a purely technical issue into a potential business risk. True recovery requires real-time visibility and control inside the browser itself.

For years, eSkimming has been treated as a short-lived “discovery moment” — a malicious script is found, removed, and the incident is closed. Our longitudinal data tells a different story. 

One year after initial discovery, 18% of previously compromised sites in our study remain actively infected, and 57% of these are running a new or evolved attack path rather than leftover code. In practical terms, nearly 1 in 6 organizations never achieve true recovery, and more than half of those face an adapted or reintroduced attack, not a simple cleanup failure.

The root cause is structural. eSkimming operates entirely within the user’s browser, while most controls — WAFs, CSPs, server-side scanners — focus on servers, networks, or static code. Remediation efforts typically remove the visible skimmer but leave the underlying condition untouched: a lack of visibility and control over what scripts do at runtime. As long as the browser remains unmonitored, attackers can quietly persist, pivot, and re-enter through new vectors that no one is watching.

To understand whether organizations truly recover from eSkimming attacks, Source Defense conducted a year-long longitudinal analysis of known victims.

 Study parameters

  • Initial dataset: ~3,600 websites identified as victims of Magecart-style eSkimming over a year ago
  • Active sample: 550 reachable, operational websites (randomly distilled from 653, excluding offline sites)
  • Geographic scope: 68 countries

Classification categories

  • Clean: No active eSkimming code detected
  • Infected: Active, functioning digital skimmers present
  • Offline: Sites no longer reachable (excluded from infection rate calculations)

By focusing only on active businesses with sufficient time to remediate, this study provides a realistic assessment of true recovery, not short-term cleanup.

Our 68-country dataset shows that eSkimming persistence is not a localized problem — it is both global and indiscriminate. While regional differences exist, no major market is immune to long-term exposure.

Our dataset spans countries across almost every continent (all except Antarctica). In our current-status sample of active sites, the two most represented countries are:

 • United States: Almost one-third of the active sites checked.
United Kingdom: Roughly 9% of the active sites.

Across all sites, 18% is the average rate of persistent attacks. Within that, two countries stand out at opposite ends of the spectrum:
Spain: The highest persistence rate in our sample, at 23%.
Germany: An outlier in the opposite direction, with an infection rate of just 4%, suggesting comparatively stronger remediation discipline or security controls.

Although rates vary by country, the pattern is consistent: Magecart operators and other eSkimming groups succeed wherever browser-side blind spots exist.

Persistence in this dataset is not just a sign of sloppy cleanup; it is evidence of attacker adaptation. Among the 98 infected sites in our active sample, 43% were still running what appeared to be the original attack, while 57% showed signs of re-infection or evolution — new code paths, alternative delivery methods, or fresh script placements. The majority of persistent cases therefore represent active re-exploitation, not passive leftovers.

Attackers clearly watch what defenders do. When organizations remove one script without addressing the exposure that made it possible, they encourage attackers to return with more resilient techniques.

Attackers don’t stick to one method. Some campaigns start in third-party code and later move into first-party JavaScript; others do the opposite or simply rotate malicious domains while keeping the same behavior. Cleaning one entry point doesn’t remove the threat — it often just pushes attackers to come back through a different path.

In our data, 12% of campaigns shifted from third-party to first-party execution over time, embedding deeper into core site logic. This kind of “digging in” typically follows partial remediation that closes obvious external vectors but leaves the underlying client-side exposure unchanged.

Remediation without runtime visibility doesn’t deter attackers — it forces innovation, and by closing one door, organizations can unintentionally guide attackers toward paths that are even harder to detect and remove.

Taken together, these findings highlight a simple reality: a browser-executed threat cannot be contained by server-side tools and one-time cleanup. Point-in-time fixes remove the skimmer you can see today; they do not control how scripts will behave tomorrow.

Effective defense requires the ability to:

  • Monitor all executing scripts, including trusted first- and third-party code
  • Detect risky or unexpected behaviors, not just patterns in network traffic or static code
  • Enforce controls during execution, before sensitive data can be skimmed or exfiltrated.

Without this, organizations remain reactive, cleaning up yesterday’s campaign while attackers quietly prepare the next one.

Source Defense was built to close this gap by eliminating the client-side blind spot. Operating directly in the browser, Source Defense provides real-time visibility into how scripts behave on the page and detects risky actions such as unexpected access to payment or other sensitive fields including fake payment forms. Behavior-based controls at runtime can prevent unauthorized data access and exfiltration and make it significantly harder for attackers to pivot to new vectors after initial cleanup. This shifts security from episodic response to continuous control over the client-side environment.

Magecart persistence is not an anomaly; it is the predictable outcome of defending a browser-executed threat with server-focused tools and point-in-time remediation. As long as organizations rely on snapshots and partial cleanup, attackers will continue to adapt, move between first- and third-party vectors, and persist in the blind spot.

And while our data cannot prove that eSkimming directly caused any specific business to go offline, the proportion of previously attacked sites that later disappear from the web should be a warning sign that leaving client-side attacks unresolved may ultimately impact the business itself, not just its security metrics.

In the browser era, visibility into client-side behavior is not optional. It is the foundation for turning “incident resolved” into recovery that actually lasts.

Copyright & Usage Notice

© 2026 Source Defense Ltd. All rights reserved.

This report and its contents are the exclusive property of Source Defense Ltd. and are provided for informational and research purposes only. No part of this publication may be reproduced, distributed, transmitted, or used in any form or by any means without the prior written permission of Source Defense Ltd, except for brief quotations used in reviews, commentary, or academic analysis with proper attribution to Source Defense Ltd.

The findings, analysis, and conclusions presented in this report are based on data available at the time of research and reflect the independent assessment of Source Defense. This report does not constitute legal, regulatory, or security advice. Organizations should evaluate their own risk and security requirements before implementing or using any of, or reliance upon, the information contained in this report and it is solely at the recipient’s own risk. Source Defense disclaims any liability regarding this report and the information and makes no representation or warranties.

For permission requests, or additional information, please contact Source Defense. support@sourcedefense.com

PCI DSS 4.0 makes client-side security a priority.

Source Defense delivers a solution for 6.4.3 and 11.6.1 without adding a burden to your security teams.

Scroll
Source Defense
Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.