What is Magecart? How E-Commerce Web Skimming Attacks Work | Visualping Blog

By The Visualping Team

Updated January 21, 2026

What is Magecart? How E-Commerce Web Skimming Attacks Work

In January 2026, security researchers at Silent Push exposed a sophisticated credit card skimming network that had been operating undetected since early 2022. The campaign targeted checkout pages across thousands of e-commerce websites, harvesting payment data from six major payment networks including American Express, Mastercard, Diners Club, Discover, JCB, and UnionPay. The attackers used heavily obfuscated JavaScript code that erased its own traces after stealing customer information.

This type of attack has a name: Magecart.

If your business processes online payments or you manage an e-commerce website, understanding how Magecart attacks work is no longer optional. According to Recorded Future's threat intelligence, Magecart attacks surged 103% in just six months during 2024-2025, making it one of the fastest-growing threats to online commerce.

This guide explains what Magecart is, how these attacks unfold, and what the recent PCI DSS 4.0 requirements mean for businesses that collect payment data online.


Important Notice: This article provides general educational information about cybersecurity threats. For implementation of security controls, compliance requirements, or incident response, consult with certified security professionals such as Qualified Security Assessors (QSAs), Certified Information Systems Security Professionals (CISSPs), or your organization's security team.


What is Magecart?

Magecart is a type of cyberattack that steals credit card information directly from e-commerce checkout pages. The name combines "Magento" (a popular e-commerce platform) with "shopping cart," reflecting the attack's origins targeting Magento-based online stores in the mid-2010s.

Today, Magecart has evolved into an umbrella term describing both the attack technique and the loosely affiliated criminal groups that use it. You may also hear these attacks referred to as web skimming, digital skimming, or formjacking. The core concept remains the same: attackers inject malicious JavaScript code into payment pages to capture credit card numbers, expiration dates, CVV codes, and billing information as customers enter them.

Unlike traditional data breaches that target databases stored on servers, Magecart attacks operate in real time within the customer's web browser. This distinction matters because it means the attack happens after data leaves the customer's device but before it reaches your payment processor. The stolen information goes directly to servers controlled by the attackers, where it is either used for fraud or sold on dark web marketplaces.

Security firm Sansec, which specializes in e-commerce threat detection, adds approximately 30 new Magecart malware signatures to its scanner every day. This volume indicates the scale of the problem and how quickly attack methods evolve to evade detection.

How Magecart Attacks Work

A typical Magecart attack follows three distinct stages. Understanding each stage helps clarify why these attacks are so difficult to detect and why traditional security tools often miss them entirely.

Stage 1: Infiltration

Attackers first need access to your website's code. They achieve this through several methods.

Exploiting vulnerabilities in your e-commerce platform is the most common approach. Magento, WooCommerce, and other platforms regularly publish security patches, but many merchants delay updates. Attackers actively scan the internet for sites running outdated software with known vulnerabilities.

Compromising third-party services represents another entry point. Modern e-commerce sites load dozens of external scripts for analytics, marketing tags, chat widgets, and social sharing features. If attackers compromise one of these third-party providers, they gain access to every website using that service. This supply chain attack method is particularly dangerous because the malicious code comes from a trusted source.

Stolen administrator credentials through phishing or brute force attacks provide direct access to content management systems where attackers can modify website code.

Stage 2: Implantation

Once inside, attackers inject malicious JavaScript code into pages that handle payment information. The code is typically obfuscated, meaning it appears as a jumbled mess of characters that is difficult for humans to read but executes normally in a browser.

The malicious script waits for customers to reach the checkout page. When someone begins entering payment information, the skimmer activates and captures every keystroke. The code may create fake payment forms that look identical to legitimate ones, intercept data entered into real forms, or modify form submission paths to send copies of the data to attacker-controlled servers.

Sophisticated attackers employ several techniques to avoid detection. Geofencing restricts the skimmer's operation to specific countries, hiding it from security researchers in other locations. Admin detection causes the code to behave normally when it detects someone logged in as an administrator, passing casual security checks. Self-destruction routines cause the skimmer to remove itself from the page after successfully capturing data, leaving no trace for forensic investigators.

Stage 3: Exfiltration

The captured payment data is transmitted to servers controlled by the attackers. This transmission often disguises itself as normal website traffic, perhaps appearing as an image request or analytics beacon. The data may be encoded or encrypted to evade detection by security tools monitoring outbound traffic.

Stolen credit cards typically appear for sale on dark web marketplaces within days. According to Recorded Future, compromised cards sell for $5 to $30 each depending on the card type, available credit limit, and freshness of the data. A single infected website serving several thousand monthly visitors can generate substantial criminal profits with minimal ongoing effort.

Why Traditional Security Misses Magecart

If you have invested in web application firewalls, intrusion detection systems, and endpoint protection, you might assume your checkout pages are secure. Unfortunately, Magecart attacks operate in a blind spot that traditional security tools cannot see.

The fundamental issue is that Magecart executes on the client side, meaning it runs in your customer's browser rather than on your server. Web application firewalls inspect traffic between users and your server, but they cannot see what JavaScript code does after it loads in a browser. The skimming and data exfiltration happen entirely on the client side, beyond the reach of server-based defenses.

This architectural blind spot explains why so many breaches go undetected for months. The malicious code operates transparently, and your server logs show nothing unusual because from the server's perspective, nothing unusual is happening.

Notable Magecart Breaches

Examining past incidents illustrates both the scope of the threat and the consequences businesses face.

British Airways (2018)

Attackers compromised British Airways' website and mobile application, stealing payment information from approximately 380,000 customers over a two-week period. The criminals customized their skimming code specifically for British Airways' website structure, demonstrating sophisticated reconnaissance. The breach resulted in a £20 million fine under GDPR, one of the largest data protection penalties issued at that time by the UK Information Commissioner's Office.

Ticketmaster (2018)

The Ticketmaster breach demonstrated the danger of third-party scripts. Attackers compromised Inbenta, a third-party chatbot provider whose JavaScript code Ticketmaster had embedded on its payment pages. The breach began in February 2018 and was not detected until April when banks noticed patterns of fraud on cards recently used at Ticketmaster. Approximately 9.4 million customers across multiple countries were potentially affected, with 66,000 credit cards confirmed compromised. The attack persisted for approximately four months before discovery. The UK ICO later fined Ticketmaster £1.25 million for failing to adequately protect customer data.

Hanna Andersson (2019)

Children's clothing retailer Hanna Andersson suffered a Magecart attack through its third-party e-commerce platform, Salesforce Commerce Cloud. The breach affected approximately 200,000 customers and led to the first class action settlement under the California Consumer Privacy Act (CCPA), with the company agreeing to pay $400,000 and implement enhanced security measures.

CosmicSting Mass Exploitation (2024)

The CosmicSting vulnerability (CVE-2024-34102) in Adobe Commerce and Magento platforms enabled mass Magecart infections throughout 2024. Sansec reported that 75% of stores remained unpatched one week after the security fix was released. Attackers exploited the vulnerability to read sensitive configuration files and inject malicious scripts into CMS blocks, affecting thousands of online stores. The incident highlighted how a single platform vulnerability can cascade into widespread Magecart deployment.

The Regulatory Response: PCI DSS 4.0

The payment card industry has recognized that traditional server-side security is insufficient to address client-side attacks like Magecart. PCI DSS version 4.0, released by the Payment Card Industry Security Standards Council, introduced specific requirements targeting this threat.

Two requirements are particularly relevant.

Requirement 6.4.3 mandates that organizations maintain an inventory of all scripts that load and execute on payment pages. Each script must be authorized and documented with a business justification. Organizations must also implement methods to verify the integrity of each script, ensuring it has not been tampered with.

Requirement 11.6.1 requires organizations to deploy change and tamper detection mechanisms for payment pages. These mechanisms must alert personnel to unauthorized modifications of HTTP headers and payment page content. Organizations must evaluate these alerts at least every seven days or establish more frequent monitoring based on risk analysis.

These requirements acknowledge a fundamental truth: preventing every possible attack is impossible, but detecting unauthorized changes quickly can minimize damage. For a detailed guide on implementing PCI DSS 11.6.1 compliant monitoring, see our comprehensive article on PCI compliance section 11.6.1.

Detection and Prevention Strategies

Protecting against Magecart requires a multi-layered approach combining proactive prevention with continuous detection.

Prevention Measures

Keep e-commerce platforms updated. Security patches address known vulnerabilities that attackers actively exploit. Establish a regular update schedule and prioritize patches for payment-related components.

Implement Content Security Policy headers. CSP allows you to specify which domains can load scripts on your pages. A properly configured CSP can prevent unauthorized scripts from executing, though it requires careful maintenance as legitimate third-party integrations change.

Minimize third-party scripts on payment pages. Every external script represents potential risk. Audit your checkout pages and remove any scripts that are not essential to the payment process.

Use Subresource Integrity for external scripts. SRI allows browsers to verify that scripts have not been modified by comparing them against known cryptographic hashes.

Detection Capabilities

Monitor payment pages for changes. Implement automated monitoring that alerts you when the content of your checkout pages changes. This includes visual changes, HTML modifications, and new script additions. Website change monitoring tools can identify unauthorized modifications before they affect many customers.

Watch for new external connections. Monitor network traffic from your website to identify unexpected outbound connections, particularly from payment pages. Skimmers must transmit stolen data somewhere, and new external destinations may indicate compromise.

Review scripts regularly. Periodically audit the JavaScript running on payment pages. Look for obfuscated code, unexpected data collection behaviors, and scripts you do not recognize. Visual regression testing can help identify unexpected visual changes that may indicate tampering.

Test transactions from customer perspective. Regular transaction testing from outside your network can help identify skimmers that might hide themselves from administrator sessions.

Website change monitoring services can automate the detection of unauthorized modifications to your payment pages. By continuously checking your checkout pages and alerting you to changes, these tools help meet the PCI DSS 11.6.1 requirement while providing an early warning system for potential compromises. Learn more about website defacement monitoring and how continuous monitoring supports your security posture.

Frequently Asked Questions

What is Magecart malware?

Magecart is malicious JavaScript code that attackers inject into e-commerce checkout pages to steal payment card information. The code operates in the customer's browser, capturing credit card numbers, expiration dates, and CVV codes as they are entered, then transmitting the stolen data to attacker-controlled servers. The term "Magecart" encompasses both the attack technique and various criminal groups that use similar methods.

How do Magecart attacks differ from traditional data breaches?

Traditional data breaches target stored information on servers, such as databases containing customer records. Magecart attacks steal data in transit by capturing payment information as customers enter it in their browsers. This client-side approach bypasses server-side security tools like web application firewalls and database encryption. Because the attack occurs in the browser, your server logs may show nothing unusual even while customers are actively being victimized.

How can I tell if my website has been compromised by Magecart?

Signs of a Magecart infection include: unauthorized JavaScript on payment pages, unexpected external script calls, modified checkout forms or new form fields, customers reporting fraudulent charges shortly after purchasing from your site, and security tools detecting outbound data transmissions to unknown destinations. However, sophisticated attacks use obfuscation and anti-detection techniques that make manual discovery difficult. Continuous automated monitoring of payment pages is the most reliable detection method.

What platforms are most targeted by Magecart attacks?

Magento (including Adobe Commerce) and WooCommerce are primary targets because of their widespread use and open-source nature, which allows attackers to study the code for vulnerabilities. However, any platform processing online payments can be targeted, including Shopify, BigCommerce, custom-built solutions, and payment pages hosted by third-party providers. The platform matters less than the security measures implemented around it.

How long do Magecart attacks typically go undetected?

Detection times vary dramatically based on security monitoring in place. The British Airways attack lasted about two weeks, while the Ticketmaster breach persisted for approximately four months. Some infections have persisted for years before discovery, as demonstrated by the January 2026 campaign that operated for over four years. Organizations with continuous payment page monitoring typically detect compromises within hours or days rather than months.

What does PCI DSS 4.0 require regarding Magecart protection?

PCI DSS 4.0 introduced requirements 6.4.3 and 11.6.1 specifically to address client-side attacks like Magecart. Requirement 6.4.3 mandates maintaining an inventory of payment page scripts with documented authorization and integrity verification. Requirement 11.6.1 requires implementing change and tamper detection mechanisms that alert personnel to unauthorized modifications of payment page content and HTTP headers. These requirements became mandatory on March 31, 2025. See our PCI DSS 11.6.1 implementation guide for step-by-step compliance instructions.

Can Content Security Policy fully protect against Magecart?

Content Security Policy provides valuable protection but is not a complete solution. CSP can prevent unauthorized scripts from loading, but it requires careful configuration and ongoing maintenance. CSP cannot protect against attacks that compromise legitimate, whitelisted domains or scripts. Additionally, some Magecart variants inject code directly into first-party scripts rather than loading external resources, bypassing CSP restrictions. CSP should be one layer in a defense-in-depth strategy that includes change detection and monitoring.

Protecting Your E-Commerce Business

Magecart attacks represent a persistent and evolving threat to any organization that collects payment information online. The attack technique exploits a fundamental blind spot in traditional security architectures, operating on the client side where server-based defenses cannot reach.

The good news is that detection is possible. By implementing continuous monitoring of your payment pages, you can identify unauthorized modifications quickly and respond before significant customer data is compromised. This approach aligns with the new PCI DSS 4.0 requirements and provides practical protection against an attack vector that has affected businesses of all sizes.

For organizations seeking to implement compliant monitoring for their payment pages, understanding the specific requirements of PCI DSS 11.6.1 is an essential first step. The same change detection capabilities that protect against Magecart also support broader compliance objectives, making payment page monitoring a foundational investment for e-commerce security.


Related Resources:


Sources

Want to stay on top of non-compliance?

Sign up with Visualping to detect issues from any web page online – before your business is on the line.

The Visualping Team

The Visualping Team creates educational content on website monitoring, competitive intelligence, and compliance. Visualping is a website change detection platform trusted by Fortune 500 companies, government agencies, and security teams worldwide to monitor web pages for unauthorized modifications, regulatory changes, and competitive updates. Our platform processes millions of page checks daily, giving us unique insight into how websites change and the security implications of those changes. This article reflects general educational information about cybersecurity threats and should not be considered professional security advice. Organizations implementing security controls or responding to incidents should consult with qualified security professionals.