What Is a Magecart Attack? How Web Skimming Steals Payment Data

A Magecart attack steals payment and personal data from ecommerce customers by compromising the website, its checkout code, or software that the page trusts. The best-known Magecart technique uses malicious JavaScript to watch a payment form in the customer’s browser, copy card data as it is entered, and send a stolen copy to attacker-controlled infrastructure while the real purchase continues normally. Magecart can also involve compromised third-party scripts, supply-chain attacks, server-side malware, and persistent backdoors.

What Is a Magecart Attack?

A Magecart attack is a form of digital payment-card skimming in which malicious code captures information from an ecommerce website or payment flow.

The term originally became associated with multiple criminal groups targeting online stores, particularly Magento-based ecommerce sites. It is now commonly used much more broadly for web-skimming activity involving compromised checkout pages, malicious JavaScript, third-party scripts, and other payment-data theft techniques.

Magecart should therefore not be understood as one single hacking group or one fixed malware family.

The basic objective is:

Compromise something the store trusts
        ↓
Place or modify skimming code
        ↓
Wait for customer checkout
        ↓
Capture payment / personal information
        ↓
Send a copy to attacker infrastructure
        ↓
Allow legitimate checkout to continue

This last step is one reason Magecart attacks can remain hidden. The attacker usually does not need to stop the transaction or display an error. The theft can happen alongside the legitimate purchase.

Because many Magecart attacks rely on malicious or compromised client-side code, monitoring the JavaScript that actually executes in the browser is an important part of detecting unexpected checkout behavior. A JavaScript vulnerability scanner can help identify security issues in deployed JavaScript and expose risky client-side behavior that may not be visible from server-side code alone.

Magecart vs Web Skimming vs Formjacking

Several terms are used for closely related attack techniques. They overlap, but they are not always perfectly interchangeable.

The most familiar Magecart implementation is a client-side JavaScript skimmer, but that is not the only possible architecture. Ecommerce security researchers have also documented server-side skimmers and persistent backend malware. Sansec’s Magecart research and malware taxonomy distinguishes browser-side and server-side skimming families.

How Does a Magecart Attack Work?

A practical Magecart attack can be understood as six stages.

1. Gain access. The attacker compromises the ecommerce platform, administrator account, vulnerable extension, deployment process, third-party supplier, tag manager, or another trusted component.
2. Plant or modify code. Malicious logic is inserted into JavaScript, HTML, a database record, template, server-side file, or externally hosted resource.
3. Wait for the payment state. The skimmer may run only on checkout pages or after particular form fields appear.
4. Capture sensitive data. The code reads information entered by the shopper.
5. Exfiltrate the stolen copy. The captured information is sent to an attacker-controlled or compromised endpoint.
6. Remain hidden. The real payment process continues, while obfuscation, selective execution, lookalike domains, or persistent malware help conceal the compromise.

A simplified browser-side flow looks like:

Customer opens checkout
        ↓
Legitimate page loads
        ↓
Malicious JavaScript executes
        ↓
Customer enters card data
        ↓
Skimmer reads payment fields
        ↓
        ├──→ Legitimate payment processor
        │
        └──→ Attacker-controlled endpoint

The store can still receive the real payment. From the customer’s perspective, checkout may appear completely successful.

How Does Magecart Get Into an Ecommerce Website?

The skimmer itself is only part of the attack. An attacker first needs a way to make malicious code execute somewhere in the payment flow.

1. First-Party Website Compromise

The attacker compromises infrastructure controlled directly by the merchant.

Potential entry points include:

• vulnerable ecommerce software
• vulnerable plugins or extensions
• stolen administrator credentials
• compromised hosting credentials
• deployment or source-control access
• database compromise
• server-side backdoors

The attacker can then alter a checkout template, JavaScript bundle, database value, or server-generated page so the customer’s browser receives the skimmer as part of the legitimate website.

2. Third-Party JavaScript Supply-Chain Compromise

An ecommerce page often executes code the merchant did not write.

Examples include:

• analytics scripts
• live-chat widgets
• marketing tags
• customer-support tools
• advertising scripts
• payment helpers
• CDN-hosted libraries
• tag-management systems

OWASP’s Third Party JavaScript Management Cheat Sheet highlights the core problem: a third-party script executing directly inside a page may access the DOM and other sensitive information available to first-party code.

If that supplier or hosted resource is compromised, the merchant can serve malicious JavaScript even though its own server files were never directly modified.

This is one specific form of the broader risk explained in our guide to JavaScript npm supply chain attacks, although Magecart is not limited to npm packages or software dependencies.

3. Tag Manager or Client-Side Configuration Compromise

Tag managers make it possible to change which scripts execute on a site without modifying the main application source code.

That flexibility is useful for marketing and analytics, but it also creates a high-value control point. If an attacker gains access to a privileged tag-management account or compromises a vendor loaded through it, malicious JavaScript may reach checkout without a traditional application-code deployment.

Security teams should therefore treat changes to payment-page tags as security-relevant code changes.

4. Server-Side Skimmers and Backdoors

Not every payment skimmer lives exclusively in the browser.

An attacker who compromises the web server may place PHP or other server-side malware that:

• captures submitted form data
• injects malicious browser JavaScript
• creates persistent backdoors
• restores the skimmer after defenders remove one visible file

This distinction matters during incident response. Removing the visible JavaScript is not enough if the server-side mechanism that generated it remains active.

What Data Can a Magecart Attack Steal?

Magecart is commonly described as credit-card theft, but a skimmer can potentially collect any information available to the compromised code.

Depending on the checkout design, that may include:

• primary account number (PAN) or card number
• cardholder name
• expiration date
• CVV or CVC
• billing address
• shipping address
• email address
• telephone number
• account information
• other personally identifiable information entered into forms

The important technical point is that a browser-side skimmer can capture data before or while the legitimate application sends it to the real payment processor.

Encryption between the customer and the merchant does not prevent malicious code already executing inside the trusted page from reading data available to that page.

Why Are Magecart Attacks Hard to Detect?

Magecart is effective because stealing the data does not require breaking the visible checkout experience.

The customer may see:

Product added
✓

Checkout opened
✓

Payment accepted
✓

Order confirmation
✓

At the same time, an unauthorized data flow may be occurring in the background.

Attackers have used several techniques to make skimmers difficult to identify:

• minified or obfuscated JavaScript
• small code changes inside legitimate files
• lookalike domains
• compromised legitimate domains
• code disguised as analytics or tag-manager logic
• selective execution only on checkout
• execution only for particular visitors or regions
• encoded or encrypted exfiltration
• self-removal or cleanup behavior
• persistent server-side backdoors that restore removed code

Historical Magecart investigations demonstrate just how subtle the change can be. Volexity’s analysis of the Newegg compromise found a small customized JavaScript skimmer inserted specifically into the billing stage of checkout, with stolen data sent to a domain designed to resemble the retailer.

Can a WAF Detect a Magecart Attack?

A web application firewall can be useful against some parts of a Magecart attack, but it should not be treated as complete protection against browser-side skimming.

The important distinction is where the malicious activity occurs.

How to Detect a Magecart Attack

Effective detection requires visibility into both the code that should exist and the behavior that actually occurs when a customer reaches checkout.

A useful investigation sequence is:

Know expected scripts
        ↓
Detect unexpected changes
        ↓
Load the real checkout state
        ↓
Observe DOM access and script behavior
        ↓
Inspect outbound browser requests
        ↓
Inspect server-side files and databases
        ↓
Investigate unexpected findings

Inventory Every Script on Payment Pages

You cannot reliably identify an unauthorized payment-page script if you do not know which scripts are authorized.

Record:

• script URL
• script owner
• business purpose
• whether it is first-party or third-party
• whether it executes on checkout
• who can approve changes

Monitor Payment Pages for Unexpected Changes

Changes to checkout HTML, script references, inline JavaScript, security headers, or tag-manager configuration deserve security review.

File-integrity monitoring can help with first-party files, but payment-page monitoring should also consider what the browser actually receives after templates, server code, third parties, and dynamic configuration have been combined.

Inspect Browser Network Activity

A checkout page should communicate with a known set of services.

Unexpected outbound requests after card fields are populated can be a strong signal worth investigating.

Look for:

• new domains
• lookalike domains
• unexpected POST requests
• encoded payloads
• network calls triggered when payment fields change
• requests made only after checkout actions

For the broader process of inspecting browser-executed code, dependencies, and deployed behavior, see our guide on how to scan JavaScript for vulnerabilities.

Do Not Ignore the Server

If a malicious client-side script is confirmed, investigate how it got there.

Review:

• modified files
• database-injected JavaScript
• administrator accounts
• scheduled tasks
• plugins and extensions
• deployment credentials
• web shells
• persistent backdoors

Finding the skimmer is not the same as finding the root compromise.

Magecart Detection Controls: What Each One Can and Cannot See

How to Prevent Magecart and Web-Skimming Attacks

No single header, scanner, or security product solves every Magecart scenario. Prevention works best when the merchant reduces the number of ways attackers can alter the payment page and quickly detects unauthorized changes when they occur.

Patch Ecommerce Software and Extensions

Keep the ecommerce platform, CMS, plugins, extensions, server software, and supporting components on maintained versions.

Internet-facing vulnerabilities can provide the initial foothold attackers need to implant a skimmer or persistent backdoor.

Protect Administrator and Deployment Access

Use strong authentication, MFA where supported, least privilege, and controlled access to:

• CMS administration
• hosting panels
• source repositories
• CI/CD
• tag managers
• CDNs
• DNS
• payment integrations

An attacker who obtains legitimate administrative access may not need to exploit a software vulnerability at all.

Reduce Third-Party JavaScript on Checkout

Every script allowed to execute on a payment page extends the trust boundary.

Ask:

• Does this script need to execute during checkout?
• Who controls it?
• Can it read payment-related DOM elements?
• How is a script change approved?
• What happens if its hosting provider is compromised?

Removing unnecessary scripts reduces both attack surface and monitoring complexity.

Use Content Security Policy Carefully

A strong Content Security Policy can restrict which script sources may execute and which destinations browser requests may reach.

That can make some skimmer techniques more difficult, particularly when malicious code tries to load from or exfiltrate data to an unauthorized origin.

But CSP is not a guarantee.

Policy trusts:
trusted-vendor.example

        ↓

trusted-vendor.example is compromised

        ↓

Origin may still be allowed by policy

Use CSP as defense in depth alongside script inventory, integrity controls, monitoring, and strong application security.

Use Subresource Integrity Where It Fits

Subresource Integrity (SRI) allows a browser to verify that an externally loaded resource still matches an expected cryptographic hash.

MDN’s Subresource Integrity documentation specifically describes SRI as protection against a supply-chain scenario where a third-party host is compromised and a JavaScript resource is changed.

A simplified example looks like:

<script
  src="https://cdn.example.com/app.js"
  integrity="sha384-EXPECTED_HASH"
  crossorigin="anonymous">
</script>

If the fetched resource no longer matches the expected hash, a supporting browser refuses to execute it.

SRI works best for resources expected to remain stable. Scripts that intentionally change frequently require a process for safely updating their integrity values.

Reduce Exposure of Payment Data to the Main Page

Where appropriate, payment architectures can reduce how much card data is accessible to the merchant’s ordinary page scripts.

Hosted payment fields, appropriately isolated iframes, tokenization, and carefully designed payment-provider integrations can reduce exposure, depending on implementation.

Isolation is valuable because a third-party script directly included in the top-level page can otherwise receive powerful access to the same browser context. MDN’s web privacy guidance notes that directly included third-party scripts effectively execute with first-party access to page data, while properly isolated cross-origin iframe content operates under a separate origin boundary.

Monitor What Customers Actually Receive

Security testing should examine the deployed checkout, not only source repositories.

Payment-page monitoring should be able to identify meaningful changes involving:

• scripts
• page contents
• security headers
• external destinations
• DOM behavior
• checkout-specific network activity

The browser is ultimately where client-side Magecart code executes, so browser-side evidence matters.

What Does PCI DSS 4.0.1 Require for Payment-Page Security?

Magecart and e-skimming are important enough that the PCI Security Standards Council has issued specific guidance around protecting ecommerce payment pages.

The PCI SSC’s Payment Page Security and Preventing E-Skimming guidance addresses PCI DSS Requirements 6.4.3 and 11.6.1.

PCI DSS Requirement 6.4.3

For applicable payment-page scripts, the control focuses on ensuring scripts are:

• authorized
• integrity protected
• inventoried
• documented with a business or technical justification

That maps directly to one of Magecart’s biggest weaknesses in ecommerce environments: organizations often do not have a reliable answer to:

“Which JavaScript is supposed to be running on this payment page?”

PCI DSS Requirement 11.6.1

This requirement focuses on detecting unauthorized modification of payment-page content and relevant HTTP headers as they are received by the consumer browser.

Conceptually:

Expected payment page
        ↓
Scripts + content + security headers
        ↓
Monitor for unauthorized change
        ↓
Generate alert
        ↓
Investigate

The requirements became effective on March 31, 2025. PCI SSC later adjusted how certain SAQ A merchants demonstrate compliance, but explicitly stated that those questionnaire changes did not remove or diminish the underlying PCI DSS requirements.

Real Magecart Attack Examples

Magecart incidents have used different initial-access paths and different skimmer implementations. The most useful historical cases are the ones that show how the attack model changes.

Ticketmaster: The Third-Party Script Problem

The Ticketmaster case is one of the clearest examples of why third-party JavaScript belongs inside a payment-page threat model.

The UK Information Commissioner’s Office documented that Ticketmaster included an Inbenta chatbot on payment pages. Attackers compromised the JavaScript hosted on Inbenta’s infrastructure, and the malicious code collected information entered by customers, including names, payment-card numbers, expiry dates, and CVV values.

The merchant’s core checkout application did not need to contain the original malicious file. Trust in the third-party script was enough to expose payment data.

British Airways: The Customer Never Needed to See an Error

The British Airways incident demonstrates the silent nature of web skimming particularly well.

The ICO’s investigation found that malicious code copied customer payment-card information to attacker-controlled infrastructure while the normal British Airways booking and payment process continued. The skimming activity remained active for approximately 15 days.

The ICO later imposed a £20 million penalty on British Airways following its investigation.

Newegg: A Small Script Can Be Enough

Volexity found malicious JavaScript specifically associated with the billing-information stage of Newegg checkout.

The attackers used the domain:

neweggstats.com

which visually resembled legitimate Newegg infrastructure. The domain also used HTTPS.

This is an important misconception to address:

A padlock and HTTPS do not prove that browser-side JavaScript is trustworthy.

Magecart in 2026: Why the Threat Still Matters

Magecart is not simply a historical threat from the 2018 wave of Ticketmaster, British Airways, and Newegg compromises.

In January 2026, Silent Push published research into an ongoing Magecart web-skimming network that its analysts traced back to at least January 2022.

The campaign included scripts associated with at least six major payment network brands:

• American Express
• Diners Club
• Discover
• JCB
• Mastercard
• UnionPay

The lesson is not that those payment networks themselves were necessarily compromised. The research shows that modern skimmers continue to target payment workflows and ecommerce customers at scale while maintaining infrastructure over long periods.

For merchants, Magecart should therefore be treated as a current client-side and ecommerce-security problem, not only as a historical case study.

Does HTTPS Prevent Magecart?

No.

HTTPS protects data while it travels between endpoints. It does not make malicious JavaScript already running inside the legitimate page safe.

Consider:

Customer enters card number
        ↓
Malicious script reads it in browser
        ↓
        ├── HTTPS → legitimate merchant
        │
        └── HTTPS → attacker server

Both network connections can be encrypted.

The Newegg attackers, for example, obtained an SSL/TLS certificate for their exfiltration infrastructure. HTTPS protected the stolen data in transit just as effectively as it protects legitimate traffic.

HTTPS is essential, but it is not a client-side malware detector.

Can CSP Prevent Magecart?

Content Security Policy can significantly reduce available attack paths, but it should not be described as complete Magecart prevention.

A well-designed CSP can:

• restrict which origins can provide executable JavaScript
• restrict inline script execution
• restrict network destinations
• generate reports when policy violations occur

But a policy that explicitly trusts a compromised script source may still allow code from that source.

CSP is strongest when combined with:

• minimal trusted origins
• script inventory
• SRI where appropriate
• runtime monitoring
• change detection
• strong access controls

What to Do If You Find a Magecart Skimmer

Deleting the visible JavaScript is not enough.

If a skimmer was active, the organization needs to determine both what information may have been exposed and how the attacker gained enough access to place the skimmer there.

1. Contain the compromise. Stop the affected payment flow or malicious resource from continuing to expose customers.
2. Preserve evidence. Save relevant files, scripts, logs, network indicators, timestamps, database records, and affected page versions before destroying useful forensic evidence.
3. Identify the skimmer. Determine exactly where it executes, what fields it reads, when it activates, and where the stolen information is sent.
4. Find the initial access path. Investigate vulnerable software, compromised accounts, third-party suppliers, deployment systems, tag managers, and server-side malware.
5. Search for persistence. Look for web shells, scheduled jobs, database injections, hidden administrator accounts, additional malware, and modified deployment processes.
6. Rotate compromised credentials. Reset affected administrative, hosting, deployment, API, cloud, and payment-related credentials where necessary.
7. Assess payment-data exposure. Establish the affected date range, customer population, data fields, and systems.
8. Follow notification and payment-industry requirements. Engage the relevant acquiring bank, payment brands, legal/privacy teams, incident-response providers, and regulators as required.
9. Rebuild trust. Restore from a known-good state rather than assuming removal of one script solves a deeper server compromise.
10. Monitor for reinfection. Continue payment-page, file, network, and browser-side monitoring after remediation.

If a website is already compromised and needs investigation and cleanup rather than general vulnerability testing, ScanTitan’s website malware removal service is designed for malware identification, cleanup, and post-compromise remediation.

Magecart Security Checklist for Ecommerce Teams

A payment-page security program should be able to answer these questions:

• Do we know every script that executes on checkout?
• Is every payment-page script authorized and justified?
• Can we detect when one of those scripts changes?
• Can third-party JavaScript access payment fields unnecessarily?
• Do we monitor unexpected outbound browser requests?
• Do we restrict script and connection origins with CSP?
• Can stable third-party resources use SRI?
• Are administrator, tag-manager, hosting, and deployment accounts strongly protected?
• Are ecommerce plugins and extensions supported and patched?
• Can we distinguish client-side skimming from server-side persistence?
• Do we monitor the payment page as the customer browser actually receives it?
• Do we have an incident-response process for exposed payment data?

Magecart prevention is ultimately a trust-management problem. The less code allowed to influence a payment page, and the better an organization understands every remaining script and change, the smaller the opportunity for a skimmer to hide in normal checkout behavior.

Frequently Asked Questions About Magecart Attacks