SVG Malware Hits Nearly 100 Magento Stores: The Invisible Skimmer You’ll Never See

Hackers have found a new way to steal your credit card — hiding a full payment skimmer inside an image so small it measures just one pixel. The attack has already compromised 99 Magento stores. The vulnerability that enabled it still has no patch for any production version of the platform.

Imagine a security scanner looking for malicious code on your website. It scans JavaScript files. It checks external script references. It analyzes network requests. It looks everywhere that malware is known to hide — and it finds nothing. Because the malware is not in any of those places. It is hiding inside an image. An image one pixel wide and one pixel tall. An image that, by design, is completely invisible to anyone looking at the page.

This is the technique behind the latest Magecart campaign discovered by Dutch e-commerce security firm Sansec. On April 7, 2026, Sansec detected a mass-infection event: 99 Magento-powered online stores compromised simultaneously with a credit card skimmer hidden inside a 1×1-pixel Scalable Vector Graphics (SVG) element. Payment data from every shopper who attempted to check out on any of those stores was being silently intercepted and exfiltrated to six attacker-controlled domains, all pointing to a single server in the Netherlands.

The campaign is sophisticated enough to fool most shoppers and most security tools — but it is also a symptom of a much larger problem. It almost certainly entered those 99 stores via PolyShell, a critical vulnerability in all production versions of Magento 2 that allows unauthenticated attackers to upload executable files via the REST API. PolyShell was discovered on March 17. Mass exploitation began on March 19. As of April 9, Adobe has still not released a patch for any production version of the platform.

The SVG Trick: How You Hide Malware in an Invisible Image

SVG is a vector image format commonly used on websites for icons, logos, and decorative graphics. Unlike pixel-based formats like JPEG or PNG, SVG files are actually XML documents — they contain markup code rather than raw image data. This is precisely what makes them useful for attackers: SVG elements can contain event handlers, including an onload attribute that executes JavaScript code when the element loads in the browser.

The attack observed by Sansec exploits this property with ruthless efficiency. The attackers inject a single SVG element into the target website’s HTML — an element sized to exactly 1×1 pixels, rendered completely invisible to any visitor looking at the page. The element’s onload attribute contains the entire skimmer payload, base64-encoded inside an atob() call and executed via setTimeout.

The critical security implication: this technique creates no external script references. Traditional security scanners look for malicious code by examining JavaScript files, checking for unauthorized script tags pointing to external URLs, and monitoring outbound network requests for suspicious domains. The SVG-based skimmer circumvents all of these detection mechanisms. As Sansec explains in its technical disclosure, “the entire malware lives inline, encoded as a single string attribute” — invisible to scanners that aren’t specifically looking for SVG onload handlers containing base64-encoded payloads.

How the Attack Works: A Step-by-Step Account

Step 1: Injection

The skimmer is injected into the Magento store’s HTML as a 1×1 SVG element, almost certainly via the PolyShell vulnerability. The element is visually invisible — it renders as a single-pixel graphic that no visitor will ever notice. The onload handler fires as soon as the page loads, decoding the base64 payload and executing the skimmer script in the browser’s JavaScript environment with full access to the page’s DOM.

Step 2: Interception

When a shopper clicks any checkout button on a compromised store, the skimmer intercepts the click event using useCapture — a technique that captures events before they reach their intended target, giving the malicious script first access to every checkout button press on the page. Instead of proceeding to the store’s real checkout, the shopper is intercepted at the moment they click.

Step 3: The Fake ‘Secure Checkout’ Overlay

The intercepted checkout attempt triggers a full-screen modal overlay — a convincing “Secure Checkout” interface, complete with a padlock icon and the visual design language of a legitimate payment form. The overlay includes card number fields with real-time Luhn algorithm validation (the standard algorithm used to verify card numbers), expiry date and CVV inputs, and a complete billing address form.

The sophistication here is deliberate. The Luhn validation makes the fake form feel authentic — shoppers who accidentally type a wrong digit see an error message, just as they would on a real payment form. The fake form provides exactly the feedback a real payment processor would provide, making it extraordinarily difficult for a typical online shopper to detect the fraud in progress.

If the shopper selects “Other payment method” from the overlay, the skimmer closes and redirects to the real checkout page — an escape hatch that prevents the attacker from losing sales that would otherwise trigger investigation if the checkout completely failed. Most victims never notice. They enter their card details, hit submit, and are redirected to the real checkout page, where the transaction completes normally. Their payment goes through. Their order arrives. And their card details are in the hands of the attackers.

Step 4: Encoding and Exfiltration

After the victim submits the fake form, the skimmer collects all input fields and encodes them using XOR obfuscation with the key “script”, followed by base64 encoding. The exfiltration URL is itself double-encoded via nested atob() calls — further complicating automated detection.

The stolen data is transmitted to one of six attacker-controlled domains, all using the same endpoint: /fb_metrics.php — disguised to look like a Facebook analytics tracker, the kind of request that appears in the network logs of millions of legitimate websites daily. The request is sent via fetch() POST with no-cors mode, which prevents CORS errors that would otherwise appear in browser developer tools. A hidden iframe serves as the fallback if fetch() is blocked.

All six exfiltration domains resolve to the same IP address: 23.137.249.67, hosted at IncogNet LLC (AS40663) in the Netherlands. IncogNet is a hosting provider with a history of use in cybercriminal operations — its bulletproof hosting model makes takedown requests slow and difficult to act on. After exfiltration, the skimmer sets a localStorage key (_mgx_cv = ‘1’) to mark the browser as already harvested, avoiding recapturing the same shopper and reducing the risk of detection through anomalous repeat submissions.

“This technique avoids creating external script references that security scanners typically flag. The entire malware lives inline, encoded as a single string attribute.”

— Sansec Security Research, April 7, 2026

PolyShell: The Unpatched Vulnerability Behind the Campaign

The SVG skimmer is a sophisticated payload. But to inject it into 99 stores simultaneously on a single day, the attackers needed a delivery mechanism — and that mechanism is almost certainly PolyShell, a critical vulnerability that Sansec discovered in mid-March 2026 and which has since become the most actively exploited flaw in the Magento ecosystem.

PolyShell is an unauthenticated file upload vulnerability in all stable production versions of both Magento Open Source and Adobe Commerce. Attackers can exploit it via the REST API to upload executable files to the target server — without logging in, without any credentials, without any prior access to the store. The vulnerable code has existed since the very first Magento 2 release, according to Sansec’s disclosure.

The scale of exploitation has been extraordinary. When Sansec disclosed PolyShell on March 17, 2026, the company immediately warned that exploitation was likely to follow quickly. It was right: mass exploitation started on March 19. By March 30 — just eleven days after mass exploitation began — 471 Magento stores were compromised in a single hour. By that same date, Sansec had observed PolyShell attacks on 56.7% of all vulnerable stores.

Adobe’s response has been inadequate by any reasonable standard. The company released a fix — but only in the pre-release version 2.4.9-alpha3+, a version not suitable for production deployment. No patch exists for any current production release of Magento Open Source or Adobe Commerce. Adobe has not responded to repeated requests for comment from Sansec. As of April 9, 2026, all production Magento 2 installations remain vulnerable to PolyShell.

The Attack Timeline: Three Weeks of Escalating Exploitation

The SVG campaign is the latest — and most technically sophisticated — event in a rapid escalation that began the moment PolyShell entered public knowledge:

The pattern is consistent with how professional Magecart groups operate: they monitor vulnerability disclosures, build automated exploitation tools, deploy mass campaigns, and iterate their payloads to avoid detection by security tools that have caught up with previous techniques. The WebRTC-based skimmer disclosed on March 24 was notable specifically because it bypasses Content Security Policy (CSP) and HTTP-based security controls — the two most widely deployed defenses against Magecart attacks. The SVG technique represents another evasion evolution.

What Is Magecart? A Persistent Threat to E-Commerce

Magecart is not a single hacking group — it is an umbrella term for a category of attack, named for the original targeting of Magento shopping carts. Today, the term describes any web-skimming operation that injects malicious JavaScript into legitimate checkout pages to intercept payment and personal data as shoppers enter it. Multiple distinct criminal groups operate within this category, sharing techniques but competing for victims.

The Magecart threat has been active since at least 2015 and has resulted in some of the largest payment card thefts in history. Notable historic victims include British Airways (500,000 customers, £183 million fine), Ticketmaster, Newegg, and thousands of smaller e-commerce merchants. Recent Magecart campaigns have targeted payment networks connected to American Express, Mastercard, Diners Club, Discover, JCB, and UnionPay — reflecting an expansion beyond individual merchant targeting to the infrastructure level.

The Magecart threat model is particularly challenging for merchants because it operates entirely within the browser, on the client side. Traditional server-side security controls — firewalls, intrusion detection systems, database monitoring — see nothing. The malicious code runs in the visitor’s browser, not on the server, which means server-side scans frequently miss active infections. This is why client-side security monitoring, continuous crawling of live page behavior, and regular integrity checks of store code are essential.

Magento’s Security History: A Platform Under Sustained Siege

The April 7 SVG campaign is the latest in a series of significant attacks against Magento and Adobe Commerce that have accelerated sharply since late 2024. The platform’s combination of widespread deployment, open-source codebase, and complex plugin ecosystem makes it a perennial high-value target for Magecart and other financially motivated threat actors.

In October 2024, Sansec disclosed CosmicSting (CVE-2024-34102) — a remote code execution flaw with a CVSS score of 9.8, the highest possible severity for a remote code vulnerability. CosmicSting was subjected to widespread exploitation and is considered one of the worst vulnerabilities to hit Magento in years. In October 2025, SessionReaper (CVE-2025-54236, CVSS 9.1) emerged — a deserialization flaw that allowed unauthenticated attackers to hijack customer sessions and take control of stores. Adobe patched SessionReaper in September 2025, but six weeks after the patch, 62% of Magento stores had still not applied it.

In April 2025, a supply chain attack compromised 21 Magento extensions from three vendors — Tigren, Meetanshi, and MGS — with backdoor code that had been silently sitting in the extensions since 2019 before activating simultaneously. Between 500 and 1,000 e-commerce stores were affected, including one belonging to a $40 billion multinational. In February 2026, a defacement campaign exploiting an unauthenticated file upload vulnerability hit 7,500 Magento stores, sweeping up Toyota, Fiat, Citroën, Asus, FedEx, Yamaha, and Lindt among its victims.

The pattern is clear: Magento is under sustained, systematic attack, and the gap between vulnerability disclosure and patch adoption — and sometimes between disclosure and Adobe’s own patch release — continues to leave large portions of the install base exposed.

“The vulnerable code has existed since the very first Magento 2 release. Adobe fixed it in the 2.4.9 pre-release branch as part of APSB25-94, but no isolated patch exists for current production versions.”

— Sansec Security Research, on the PolyShell vulnerability

Indicators of Compromise (IoCs) and Technical Details

For security teams and Magento administrators, the following indicators of compromise can be used to detect active infections or assess whether a store has already been compromised:

What Store Owners Must Do Right Now

With no production patch available for PolyShell, Magento store owners cannot rely on a standard patching cycle to protect themselves. The following mitigation steps are recommended by Sansec and independent security researchers:

Scan for the SVG injection immediately. Search all site files and database entries for SVG elements containing an onload attribute with atob() function calls. These are not legitimate in standard Magento themes and indicate active compromise. Remove any such elements found.

Check localStorage for the marker key. If the key _mgx_cv is set to ‘1’ in your browser’s localStorage when visiting your store’s checkout, payment data has been exfiltrated from that browser session. This is a fast check that does not require server access.

Block traffic to the exfiltration infrastructure. Block all traffic to IP address 23.137.249.67 and monitor for outbound requests to /fb_metrics.php on any unfamiliar domain. Deploy firewall rules to prevent communication with IncogNet LLC (AS40663) if your business has no legitimate use for that network range.

Restrict REST API file upload endpoints. The PolyShell vulnerability operates through Magento’s REST API. Implement WAF rules to block unauthorized file upload attempts via API endpoints. Sansec Shield is specifically designed to block PolyShell exploitation attempts in real-time while administrators plan a patching strategy.

Upgrade to Magento 2.4.9 when available. Adobe’s fix for PolyShell (APSB25-94) is available in the 2.4.9 pre-release. While deploying a pre-release version in production is generally inadvisable, the severity of the vulnerability may justify accelerated testing and deployment for high-value stores. Monitor Adobe’s security bulletins for the formal production patch release.

Implement client-side security monitoring. Because Magecart attacks operate in the browser, server-side security scanning frequently misses them. Deploy client-side monitoring tools that continuously crawl your live checkout pages looking for unauthorized scripts, DOM modifications, and suspicious network requests. Sansec eComscan is specifically designed for this use case.

What Shoppers Should Know

For consumers, the SVG skimmer campaign illustrates a fundamental truth about Magecart attacks: there is almost no way to detect them at the point of purchase. The fake checkout overlay looks authentic, validates card numbers in real time, and completes the purchase normally after stealing your data. The experience is indistinguishable from a legitimate checkout.

The most effective consumer-side protections do not involve trying to detect the attack at checkout — they limit the damage if you are caught in one. Using virtual or single-use card numbers (available through services like Privacy.com and from many major card issuers) means any stolen card number has a limited lifespan and spending scope. Enabling transaction alerts via SMS or email means suspicious charges will be detected quickly. Choosing payment methods that route through isolated third-party gateways (PayPal, Apple Pay, Google Pay) means your card details never reach the merchant’s website at all — and therefore cannot be skimmed.

Monitor your bank and card statements actively in the weeks following any online purchase. Magecart operators typically wait days or weeks before using stolen card data to avoid triggering fraud detection systems that flag immediate unusual activity. A charge appearing two weeks after you shopped at an unfamiliar site is a red flag worth investigating.

A Reminder That the Attack Surface Is Everywhere That Shoppers Are

The SVG skimmer campaign is technically clever, and the PolyShell vulnerability is severe. But the deeper problem they reveal is neither new nor surprising: a large fraction of the e-commerce web runs on software that is persistently under-patched, inconsistently monitored, and attacked by sophisticated criminal groups who invest continuously in evading the latest detection methods.

The 99 stores compromised on April 7 are not outliers — they are representative of a much larger ecosystem of vulnerable Magento installations that have not applied available patches, are not running real-time monitoring, and have no visibility into what JavaScript is executing in their customers’ browsers at checkout. Sansec estimates that PolyShell alone has already affected more than half of all vulnerable stores.

Adobe’s failure to provide a production-version patch for a critical vulnerability that has been mass-exploited for three weeks is a governance failure that deserves direct acknowledgment from the company. Merchants running Magento have a right to expect that when a zero-day vulnerability in their platform is publicly disclosed and actively mass-exploited, their platform vendor will prioritize an emergency production patch above all other development work. That has not happened here.

Until that patch arrives, every production Magento store is at risk. The SVG skimmer currently infecting 99 of them is one payload among many that PolyShell is already delivering. The most invisible attacks, as this campaign demonstrates, are often the most dangerous ones.