Protecting the payment page Is not enough: The SVG magecart shift

PROTECTING THE PAYMENT PAGE IS NOT ENOUGH: THE SVG MAGECART SHIFT

What makes this campaign especially dangerous is not just the skimming itself, but the blind spot it exploits. PCI DSS 4.0.1 Requirements 6.4.3 and 11.6.1 focus on the payment page, and many organizations have built their defenses around that same boundary. This campaign shows why that boundary was never enough. Instead of attacking the final checkout page, the attackers steal card data earlier in the customer journey, on product, cart, or other pre-checkout pages that many teams treat as lower risk. That creates a false sense of safety: the real checkout may still look intact, while sensitive data is captured before the customer ever reaches it. The unusual twist is the abuse of a tiny SVG image element, a standard browser feature repurposed to quietly launch malicious code and display a convincing fake checkout experience that looks legitimate to the shopper.

Attack details

The attack uses malicious first-party page execution delivered through injected inline code rather than a visible external script reference. It begins with a nearly invisible 1×1 SVG element whose “onload” event launches obfuscated JavaScript. That code attaches capture-phase event listeners to checkout-related buttons so it can intercept the shopper’s click before the site’s normal checkout flow takes over. The victim is then shown a counterfeit payment modal designed to look legitimate, complete with security branding and real-time card validation that reduces suspicion. After the shopper enters billing and payment information, the data is exfiltrated to attacker-controlled infrastructure. The fake overlay then disappears and the user is redirected to the legitimate payment page, making the interaction look like a normal refresh or transition. This is the critical twist: the payment page itself can remain untouched while card data is stolen earlier, on pages that are frequently outside the focus of strict script monitoring and integrity controls.

How Source Defense protects youSource Defense helps organizations close the gap between payment-page compliance and real client-side security. In this attack, that matters because the skimming happens before the official checkout page, even though many security programs still focus their controls on the payment step. Source Defense extends visibility across the user journey, helping security teams identify malicious behavior such as unauthorized access to payment data, risky inline execution, and browser-based data transfers before stolen information reaches an attacker-controlled destination. That behavior-based approach is critical here because the threat is hidden inside trusted page content and activated through normal browser functionality rather than an obvious external script. Source Defense also surfaces actionable alerts when this behavior occurs, including:

• Sending data to a blacklisted domain
• Accessing PCI data
• Accessing data
• Transferring data
• Executing risky actions 

These alerts appear in the bell notification center, dashboard summaries, and the “Script behaviors” widget, and can also be sent by email and/or webhook depending on configuration. By monitoring what code does in the browser, not just whether the final payment page changed, Source Defense helps security teams detect skimming activity earlier in the customer journey and reduce exposure in the pages attackers increasingly target.

This version follows the GPT logic correctly and keeps the upgrade message intact without explicitly calling out different coverage levels.

Key takeaways

This campaign highlights a structural weakness in payment-page-focused security strategies. When organizations concentrate protection too narrowly on the final checkout URL, attackers can shift earlier in the customer journey, where trust is high and monitoring is often lighter. That is exactly what makes this campaign effective: the legitimate payment page can remain untouched while card data is stolen before the real transaction begins. It also underscores a broader problem with PCI DSS 4.0.1 Requirements 6.4.3 and 11.6.1: by limiting those controls to the payment page, the standard reflects a compliance boundary that attackers do not follow. Traditional controls such as CSP, SRI, WAFs, and server-side logging still play a role, but they do not provide complete visibility into malicious behavior running inside the browser. Effective defense requires client-side security that protects the full path to payment, from product and cart pages through checkout, so attackers cannot exploit the gaps in between.