SVG Pixel Trick Hides Magento Credit Card Skimmer

SVG Pixel Attack Hits Nearly 100 Magento Stores

A large-scale credit card skimmer campaign is actively targeting Magento-powered online stores by hiding malicious payloads inside a 1x1-pixel SVG element. The technique is deliberate and effective: a single invisible image tag carries an entire inline skimmer, no external script files, no obvious network requests to flag. Security researchers at Sansec discovered the campaign and linked the initial access vector to PolyShell, a critical unauthenticated remote code execution vulnerability disclosed in mid-March 2026 that affects all stable Magento 2 and Adobe Commerce installations.

Nearly 100 stores have been confirmed compromised. Adobe has not yet shipped a patch for production versions.

How the SVG Injection Technique Works

The attacker injects a <svg> element with dimensions of 1x1 pixel directly into the store's HTML. That element carries an onload attribute containing the full skimmer payload, encoded with atob() and fired through setTimeout. Because the malicious code lives as an inline string attribute rather than a separate script file, it sidesteps most scanner heuristics that look for external script references or suspicious <script> tags.

When a customer clicks checkout, the injected script intercepts the event and renders a convincing "Secure Checkout" overlay. The overlay mimics a legitimate payment form, collects card details and billing information, then validates card numbers in real time using the Luhn algorithm. Exfiltration happens via XOR-encrypted, base64-obfuscated JSON sent to attacker-controlled domains. Sansec identified six exfiltration endpoints, all hosted at IncogNet LLC (AS40663) in the Netherlands, each receiving stolen data from 10 to 15 victim stores.

What Developers and Store Owners Are Exposed To

The risk here is not just reputational. If your store is processing live transactions while compromised, every card submitted goes to the attacker before it reaches your payment processor. PCI DSS scope violations, chargebacks, and potential fines follow. The fake overlay is convincing enough that users have no visual cue that anything is wrong.

The PolyShell vulnerability compounds this. Because it allows unauthenticated code execution, attackers can gain initial access without needing stolen admin credentials. Earlier waves of PolyShell attacks also deployed WebRTC-based exfiltration channels, suggesting the attacker group is iterating on their methods quickly.

How to Detect and Remediate This Attack

Sansec has outlined specific detection steps worth running immediately if you operate a Magento store.

• Search your site's HTML and template files for <svg> tags that include an onload attribute containing atob(). Remove any you find and audit how they got there.
• Check browser localStorage for a key named _mgx_cv. Its presence indicates payment data was likely captured.
• Review server and CDN logs for outbound requests to /fb_metrics.php or any analytics-style domains you do not recognize.
• Block traffic to IP address 23.137.249.67 and all domains resolving to it at the firewall or WAF level.

On the patch side, Adobe has only released a fix in the pre-release build 2.4.9-alpha3+. That is not a production-ready update, but if your risk tolerance allows it, running the beta is safer than leaving a fully vulnerable installation exposed. Apply all available mitigations in the meantime and audit your checkout flow for injected elements. You can also run an automated scan of your storefront to detect inline script anomalies and suspicious DOM modifications before customers encounter them.

For broader context on web skimming attack patterns, see our writeup on detecting Magecart-style attacks.

Why doesn't a WAF catch this attack? Most WAF rules look for external script loads or known malicious domains in request headers. This skimmer is entirely inline, embedded as a string attribute in an SVG tag. No external request is made until after the card data is already captured, so the injection phase slips past rules focused on script-src violations.

How did the attacker get into these stores in the first place? The leading theory from Sansec is exploitation of PolyShell, a Magento 2 vulnerability that allows unauthenticated remote code execution. No stolen credentials are required. Any publicly reachable Magento 2 installation on a stable release without mitigation applied is a valid target.

Is upgrading to the alpha build safe for production stores? Generally, no. Pre-release builds are not supported for production use and may introduce instability. Apply the available mitigations, restrict admin access, and monitor your checkout flow actively until Adobe ships a stable patch.

Scan your Magento store for SVG injection and skimmer threats now at VibeWShield.