Magecart attacks: how ecommerce stores get compromised and how to prevent it

Magecart is not a single hacker group. It is a technique. JavaScript skimming, formjacking, web skimming: the method involves injecting malicious JavaScript code onto checkout pages to capture payment card data as users type it, before it is submitted to the payment processor. The captured data is sent silently to attacker-controlled servers.

The technique was first observed in large-scale ecommerce attacks in 2015. By 2018, it had hit British Airways, Ticketmaster and hundreds of other major brands. In 2020, researchers from Malwarebytes found Magecart code on over 10,000 websites simultaneously. The attacks continue today.

PCI DSS 4.0 Requirements 6.4.3 and 11.6.1, which became mandatory in March 2025, exist specifically to address Magecart. Understanding the attack is essential to understanding the compliance requirement.

How JavaScript skimming works

A browser executes JavaScript from any source referenced on a page, with equal privilege. There is no sandbox between a first-party script (your checkout code) and a third-party script (a chat widget, analytics pixel or A/B testing tool). Both can read the DOM, both can observe user input, both can send network requests.

A Magecart skimmer exploits this. Once injected, the skimmer code listens for form input events on payment fields: card number, expiry date, CVV, cardholder name. When the user types their card number, the skimmer captures it character by character. When the form is submitted, the skimmer sends the captured data to an external endpoint (often a domain that looks similar to a legitimate service: googletagmanager-cdn.net instead of googletagmanager.com) and then allows the normal form submission to proceed.

The user never knows. The payment processes normally. The card is stolen silently. The average time between injection and detection in documented Magecart breaches is 22 days. During that window, every customer who completes checkout has their card compromised.

Attack vectors: how Magecart gets onto your site

There are four primary attack vectors:

• Direct compromise of the ecommerce platform: exploiting a vulnerability in the platform software (Magento, WooCommerce) or an installed plugin to inject code directly into checkout page templates. The 2020 wave of attacks exploited unpatched Magento vulnerabilities to inject skimmers directly into the server-side templates.
• Third-party script supply chain attack: the attacker compromises a vendor whose JavaScript is loaded on checkout pages. The skimmer is added to the vendor's script. Every site that loads that vendor's script is compromised. This is how British Airways and Ticketmaster were hit in 2018: the attacker compromised a shared third-party supplier (Inbenta for Ticketmaster, believed to be a Baggage Claim JavaScript library for BA) and injected the skimmer into the vendor's script.
• Compromised CDN or infrastructure: attackers who gain access to a content delivery network can modify cached scripts. Sites that load scripts from CDN without integrity verification are vulnerable.
• Formjacking via iframe manipulation: rather than injecting into the page directly, some variants create a hidden form overlay that captures keystrokes before they reach the legitimate payment iframe.

British Airways breach: 380,000 cards stolen

In August 2018, attackers injected a 22-line JavaScript skimmer onto the British Airways booking page. The script captured all form fields including card number, expiry, CVV and personal details. It ran from August 21 to September 5, 2018: 16 days.

The attacker registered a domain (baways.com) that appeared similar to British Airways. The stolen data was exfiltrated to a server at that domain. 380,000 customers who made bookings during the window had their payment data and personal information stolen.

The UK Information Commissioner's Office issued an initial fine of £183 million under GDPR (later reduced to £20 million after COVID-19 financial impact considerations and British Airways' response). The breach cost British Airways hundreds of millions in total: the fine, remediation, customer notifications, legal fees and reputational damage.

The technical vector: attackers compromised a Modernizr JavaScript library being loaded on the BA booking page. The specific entry point was the baggage claim script loaded from a third-party CDN. The skimmer was injected into that script. Because BA had no script integrity checking, the modified script executed without any alert.

Ticketmaster breach: 40,000 customers affected

In June 2018, Ticketmaster disclosed a breach that affected approximately 40,000 UK customers. The vector was a chatbot script provided by Inbenta Technologies, a third-party customer support vendor.

Inbenta confirmed that their JavaScript had been modified by attackers. The modified script was loaded on Ticketmaster's payment pages. Because the script ran in the browser with full DOM access, it captured payment card data entered on checkout.

Inbenta stated that the script was designed for use on informational pages, not payment pages, and that Ticketmaster's decision to use it on checkout pages was not intended by Inbenta. This illustrates the supply chain responsibility question: Ticketmaster was responsible for vetting every script on their payment pages.

Claire's 2020: Magento exploitation

In April 2020, Claire's and Icing (both brands of Claires Stores Inc.) were found to have Magecart skimmers injected via a compromised Magento plugin. The skimmer was active from April 25 to June 13, 2020.

The attack exploited a vulnerability in the Magento backend to inject the skimmer script directly into the theme files. The skimmer targeted form fields on the checkout page and exfiltrated data to a domain designed to appear as a CDN (claires-assets.com).

The Claire's breach was discovered by Sansec, a Dutch cybersecurity company that monitors ecommerce stores for skimmer activity. It was not discovered internally by Claire's. This is characteristic of Magecart attacks: they are designed to be invisible and are rarely discovered through internal monitoring.

How PCI DSS 4.0 responds to Magecart

PCI DSS 4.0 Requirement 6.4.3 and 11.6.1 were written in direct response to the Magecart threat model. The PCI Security Standards Council was explicit about this in their guidance documentation.

Requirement 6.4.3 addresses the supply chain attack vector: maintain an inventory of all scripts on payment pages, ensure each is authorized and protect them from modification. SRI hashes verify that authorized scripts have not been modified. CSP prevents unauthorized scripts from loading.

Requirement 11.6.1 addresses detection: implement a mechanism to detect unauthorized changes to HTTP headers and payment page content. A store that is actively monitoring for script changes will detect a Magecart injection within hours, not weeks.

Together, the requirements create a prevent-and-detect framework. Prevention (6.4.3) reduces the probability that a skimmer successfully executes. Detection (11.6.1) reduces the dwell time if one does.

Detection methods

Multiple technical controls can detect Magecart activity:

• CSP violation reporting: a Content Security Policy configured for the checkout page will block any script not on the whitelist and report the blocked attempt. A Magecart script loading from an unlisted domain generates an immediate CSP violation report. Requires enforce mode to block, Report-Only to detect without blocking.
• Subresource Integrity: SRI hashes on third-party script tags verify that the loaded script matches the expected hash. A compromised third-party script (like the Inbenta script in the Ticketmaster case) would have a different hash and fail to load.
• DOM mutation monitoring: server-side or client-side monitoring that detects when new script elements are added to payment pages or when existing scripts are modified. Sansec's commercial product, Magento's built-in file integrity monitoring, and custom periodic page fetching and diffing all implement this.
• Network egress monitoring: detecting outbound connections from payment pages to unexpected domains. CSP's connect-src directive blocks this at the browser level. Server-side network monitoring can detect it at the infrastructure level.
• File integrity monitoring: hash-based monitoring of server-side template files. If a checkout template file's hash changes unexpectedly, an alert fires. This is Requirement 11.5.2 in PCI DSS 4.0.

Response playbook when you detect a skimmer

Time matters. Every minute a skimmer is active increases the cardholder data exposed. The response sequence:

• Take checkout offline immediately: the priority is stopping the bleeding. A maintenance page on checkout while you investigate is better than continued exposure. If you use a hosted checkout (Shopify, Stripe Checkout) and the skimmer is in your storefront rather than the checkout, the payment data may not be at risk but investigate before assuming.
• Preserve evidence: take snapshots of affected pages and server logs before making changes. Your forensic investigation and any regulatory reporting will need this.
• Identify scope: determine which pages were affected, how long the skimmer was active and how many transactions occurred during the window. This defines the scope of cardholder data potentially compromised.
• Remove the skimmer: identify the injection point (compromised vendor script, direct file modification, CMS plugin) and remove it. Verify integrity of all files in scope.
• Notify your acquiring bank: PCI DSS requires notification to your acquirer in the event of a suspected or confirmed breach. Your acquirer will initiate the PCI forensic investigation process.
• Engage a PCI Forensic Investigator (PFI): a qualified forensics firm will conduct the investigation required by payment card networks. This is mandatory for breaches above a certain transaction threshold.
• Customer notification: depending on jurisdiction, you may be required to notify affected customers within specific timeframes. GDPR requires notification within 72 hours of becoming aware of a breach.

Prevention checklist

• Implement CSP in enforce mode on checkout pages with a strict allowlist of script sources.
• Add SRI hashes to all third-party script tags on payment pages. See our guide on payment page security for the full checklist.
• Maintain a script inventory documenting every script on payment pages with its purpose and approval status.
• Set up CSP violation reporting with real-time alerting to catch injection attempts immediately.
• Monitor payment page content for unauthorized changes via automated periodic comparison.
• Keep platform and plugins up to date. The Claire's breach exploited unpatched Magento. Patch cadence is your first line of defense. A regular penetration testing schedule helps validate your patching process.
• Vet third-party script vendors before adding their scripts to checkout pages. Ask for their security practices and incident history.
• Review all GTM tags before they go live on checkout pages. Marketing tags on checkout are a major attack surface.

Frequently asked questions

What is a Magecart attack?

A Magecart attack is a JavaScript skimming technique where malicious code is injected into ecommerce checkout pages to capture payment card data as customers type it. The stolen data is sent to attacker-controlled servers while the page functions normally.

How long do Magecart attacks go undetected?

The average time between injection and detection in documented Magecart breaches is 22 days. Some attacks have run undetected for months because the payment page continues to function normally.

What PCI DSS requirements address Magecart attacks?

PCI DSS 4.0 Requirements 6.4.3 and 11.6.1 were written specifically to address Magecart. Requirement 6.4.3 covers script inventory and authorization. Requirement 11.6.1 covers tamper detection for payment pages.

How do I detect a Magecart skimmer on my site?

Use Content Security Policy violation reporting for real-time detection, Subresource Integrity hashes to block modified scripts and automated browser-based monitoring that compares payment page content against a known-good baseline.