Category: Incident Response and Skimming

Magecart

Also known as: Web skimming, Formjacking, Magecart attack, Digital skimming

Simply put

Magecart refers to a style of online attack, and to the loosely related threat actors behind it, in which criminals sneak malicious code into an e-commerce website to steal payment card details as shoppers enter them at checkout. Rather than breaking into a stored database, the code quietly captures data from the online payment form and sends it to the attacker. Because the theft happens in the customer's browser as they type, shoppers and merchants often do not notice it right away.

Formal definition

Magecart is an umbrella term describing both a category of client-side web skimming (also called formjacking) attacks and the various threat actor groups associated with them, targeting e-commerce checkout and payment pages. Attackers inject malicious JavaScript into a website—either directly or through a compromised third-party script or supply-chain component—to intercept data entered into HTML payment forms and exfiltrate it to an attacker-controlled endpoint. Captured fields may include cardholder data such as the PAN, cardholder name, and expiration date, as well as sensitive authentication data such as the CAV2/CVC2/CVV2/CID entered at checkout; because the skimmer harvests values in the browser at the point of entry, it can capture sensitive authentication data that must not be stored after authorization. Magecart activity is a client-side threat that operates outside the merchant's server-side controls and can evade defenses focused solely on stored data, making script integrity monitoring, content controls over third-party scripts, and browser-side change detection relevant mitigations; these controls help reduce but do not guarantee prevention of skimming.

Why it matters

Magecart attacks strike at a point that many traditional payment security programs do not fully cover: the customer's browser at the moment of checkout. Controls that focus on protecting stored data—database encryption, access controls on back-end systems, and monitoring of server-side environments—do little to stop a skimmer that harvests card details as they are typed into an HTML payment form. Because the malicious code captures values at the point of entry, it can intercept sensitive authentication data such as the CAV2/CVC2/CVV2/CID that must never be stored after authorization, giving attackers exactly the data needed for card-not-present fraud.

The threat is compounded by its stealth and its supply-chain dimension. Skimming code is often introduced not by directly compromising the merchant's own site but by tampering with a third-party script the site already loads, meaning a single compromised component can affect many merchants at once. Shoppers and merchants frequently do not notice the theft for some time, since the checkout page continues to function normally while data is quietly exfiltrated to an attacker-controlled endpoint. Reported campaigns have targeted checkouts tied to major payment networks, illustrating that the technique remains actively used against live e-commerce environments.

Who it's relevant to

E-commerce merchants

Merchants operating online checkout pages are the primary targets. Because skimming captures data in the shopper's browser rather than from a stored database, merchants need visibility into the scripts running on their payment pages—including third-party components they did not write—rather than relying only on protections for stored cardholder data.

Security engineers and application security teams

Teams responsible for web application security should treat Magecart as a client-side and supply-chain threat. Script integrity monitoring, controls over which third-party scripts can execute on checkout pages, and browser-side change detection are relevant defensive measures, though none should be assumed to fully eliminate skimming.

Compliance officers

Because skimmers can capture sensitive authentication data such as CAV2/CVC2/CVV2/CID at the point of entry—data that must not be stored after authorization—Magecart is relevant to how organizations think about protecting the payment page and the third-party scripts loaded onto it. Readers should confirm applicable requirements against the current published standard rather than assuming a fixed requirement number.

Fraud analysts and merchant risk teams

Card data stolen through web skimming is well suited to card-not-present fraud, since attackers capture the exact values a shopper enters at checkout. Fraud teams may see downstream effects even when their own systems were not directly breached, particularly when the compromise originated in a shared third-party component.

Inside Magecart

Digital skimming (formjacking)

The core technique associated with Magecart activity, in which malicious JavaScript is injected into an e-commerce checkout page to capture cardholder data and, critically, sensitive authentication data such as the CVV2/CVC2/CID entered by the customer at the point of data entry, before it would otherwise be handled by protected systems.

Client-side execution context

Magecart-style attacks typically operate in the customer's browser rather than on server-side systems, which means the malicious code can access data as it is typed into web forms. This client-side vantage point is why data that must not be stored after authorization can still be harvested during entry.

Third-party and supply-chain scripts

Injection frequently occurs through compromised third-party components loaded into checkout pages, such as analytics, chat widgets, tag managers, or content delivery dependencies. A single compromised dependency can affect many merchants that load the same script.

Exfiltration channel

Captured data is sent to attacker-controlled infrastructure, often disguised to blend with legitimate traffic. The destination and encoding are chosen to evade casual inspection of outbound requests.

Targeted data

The data sought commonly includes cardholder data (such as PAN, cardholder name, and expiration date) together with sensitive authentication data (such as the card verification value entered during a card-not-present transaction). Sensitive authentication data must not be stored after authorization even when encrypted, which underscores why interception during entry is the attacker's goal.

Relevant PCI DSS control areas

Payment page script integrity and change-/tamper-detection expectations, along with malware and vulnerability management controls, are the requirement areas most relevant to this threat. Requirement numbering and wording differ between PCI DSS versions, so practitioners should confirm the applicable requirements against the current published standard rather than assuming a fixed number.

Common questions

Answers to the questions practitioners most commonly ask about Magecart.

Is Magecart a single hacking group?

No. Magecart is not a single organization but a term used to describe a loose set of threat actors and campaigns that share a common technique: injecting malicious scripts into web pages to skim payment data. Multiple distinct groups operate under this umbrella label, using varied infrastructure and methods. Treating Magecart as one entity can lead teams to underestimate the diversity of tactics they may face.

Does encrypting or tokenizing data on my servers protect against Magecart skimming?

Not necessarily. Magecart-style attacks typically capture cardholder data and, where present, sensitive authentication data such as CVV2/CID directly in the customer's browser at the point of entry, before server-side encryption or tokenization is applied. Because the malicious script runs in the client's page, controls that transform data after it reaches your systems may not mitigate this client-side interception. Client-side integrity and script controls address a different layer than server-side data protection.

How can I detect malicious script changes on my payment pages?

Approaches include monitoring for unauthorized changes to scripts loaded on payment pages, maintaining an inventory of authorized scripts and their sources, and using integrity mechanisms to flag unexpected modifications. Current PCI DSS versions include requirements addressing the management and integrity of scripts on payment pages; confirm the exact requirement wording and numbering against the current published standard, as these differ between versions. Detection controls can produce false positives from legitimate updates and false negatives against sophisticated or obfuscated injections, so monitoring should be paired with change management.

How should I manage third-party and fourth-party scripts on checkout pages?

Maintain an inventory of all scripts executing on payment pages, including those loaded indirectly through third-party tags that themselves pull in further dependencies. Justify why each script is present, confirm its source, and monitor for changes. Because a compromise of a trusted third-party provider can propagate to your pages, controls should account for scripts you do not directly host. Validation of these controls depends on your specific implementation and should be confirmed against the current PCI DSS requirements.

Can a Content Security Policy help reduce Magecart risk?

A Content Security Policy may help by restricting the origins from which scripts can load and where data can be sent, which can limit some exfiltration paths. However, it is intended to reduce risk rather than eliminate it, and its effectiveness depends on correct, restrictive configuration and ongoing maintenance. It does not address injections that abuse already-permitted origins, and it should be treated as one layer within a broader set of script integrity and monitoring controls.

What does moving to a hosted or iframe-based payment page change about my exposure?

Redirecting or embedding the payment form via a hosted page or iframe controlled by a validated service provider can shift where cardholder data is entered and captured, which may reduce the portions of your environment in PCI DSS scope. The effect on scope depends on the specific implementation and how it is validated, not on the technique's label alone. Note that the parent page delivering the redirect or iframe can still be a target for manipulation, so integrity controls on that page remain relevant.

Common misconceptions

Magecart is a single hacking group or a specific piece of malware.

The term is used broadly to describe client-side digital skimming activity attributed to multiple actors using varied techniques, rather than one fixed group or one named tool. The unifying element is the method, not a single perpetrator.

Encrypting or tokenizing stored card data protects against Magecart-style attacks.

These attacks typically capture data client-side, as it is entered, before it reaches systems where encryption, tokenization, truncation, or masking would apply. Those data-protection measures transform data differently and address stored or transmitted data, so they do not by themselves stop interception at the point of entry.

Because the compromised script is often a third-party component, the merchant carries no responsibility for the exposure.

Scripts loaded into a merchant's checkout page execute in the context of that page. Managing which scripts load, and monitoring them for unauthorized change, generally falls within the merchant's control responsibilities, even when the underlying component is supplied by a third party.

Best practices

Inventory and minimize the scripts loaded on payment pages, removing unnecessary third-party components and restricting what can execute in the checkout context.

Implement mechanisms to detect unauthorized change or tampering of payment page scripts, and review the current PCI DSS requirements for payment page script integrity and change detection to confirm what applies to your version and environment.

Recognize that sensitive authentication data can be captured at the point of entry, and design controls to reduce exposure of the data-entry flow rather than relying only on protections applied to stored data.

Monitor outbound requests from payment pages for unexpected destinations or exfiltration patterns, while accounting for the false-positive and false-negative trade-offs of such detection.

Apply supply-chain and dependency governance, including vetting, integrity controls, and change awareness for third-party scripts and their upstream sources.

Maintain malware and vulnerability management practices across the systems and delivery paths that serve payment pages, and validate control effectiveness against the current published standard rather than assuming a fixed requirement number.