PolyShell Exploitation And SVG-Based Skimmers In Magecart Attacks

Magento merchants face a rapidly escalating threat landscape. Attackers now combine newly disclosed exploitation techniques with stealthy payment skimmers to compromise online stores at scale. These incidents are often referred to as Magecart attacks. Sansec security researchers report that threat actors exploit the critical PolyShell vulnerability in Magento and Adobe Commerce.

This grants attackers unauthenticated access to vulnerable e-commerce environments. Once inside, they deploy Magecart malware that hides within seemingly harmless SVG image elements. The combined attack chain shows how quickly attackers can exploit new vulnerabilities and adapt their tools to evade detection.

PolyShell, disclosed by Sansec in March, affects Magento Open Source and Adobe Commerce version 2 installations. It exploits a flaw in the platform's REST API for file uploads. The vulnerability allows unauthenticated attackers to upload polyglot files. These files are both valid image files and executable scripts. Depending on server configuration, attackers can use the flaw for remote code execution or to trigger stored cross-site scripting that leads to account takeover. Since exploitation requires no authentication, the flaw is a severe risk to internet-facing Magento stores.

Researchers initially warned that active exploitation had not yet begun when PolyShell was disclosed. However, this grace period was short. Within days, Sansec observed widespread attacks targeting exposed stores. The firm says attackers began mass exploitation on March 19. By next week, over 56% of vulnerable Magento stores in the wild will have been targeted. The speed of weaponization shows defenders have little time to respond when new e-commerce vulnerabilities emerge.

The PolyShell flaw is dangerous due to its reach and the flexibility it gives attackers once they compromise a store. Inside a Magento environment, threat actors can upload web shells or implant backdoors. They can also modify store templates or inject JavaScript skimmers into checkout workflows.

Researchers have already linked the flaw to campaigns involving payment theft malware. In some cases, attackers deploy evasive WebRTC-based skimmers that exfiltrate card data over encrypted DTLS/UDP rather than via regular HTTP requests. This helps the malware bypass Content Security Policy restrictions and evade network monitoring tools.

A new, notable development in these attacks is an SVG-based skimmer campaign recently found by Sansec. It hides malicious code inside nearly invisible SVG elements. Researchers found the campaign in almost 100 Magento stores. In these cases, attackers injected a 1x1-pixel SVG tag into the page's HTML and embedded the full skimmer payload in the SVG's onload attribute. The payload is base64-encoded text wrapped in an atob() function. It runs automatically with JavaScript timing functions as soon as the SVG loads in the victim's browser.

This approach gives attackers a strong stealth advantage. Traditional Magecart skimmers often use externally loaded JavaScript or visible inline scripts. Defenders can find these with integrity monitoring or content security controls. By embedding the skimmer in an SVG image element, attackers hide malicious logic in a place most scanners and defenders do not check. The SVG is only one pixel, so it is invisible to shoppers and hard for site administrators to notice during regular page reviews.

SVG Onload Attack Chain

When loaded in the browser, the SVG-based skimmer intercepts user checkout actions before the legitimate payment workflow begins. Instead of sending shoppers directly to their actual checkout page, the malware displays a fake "Secure Checkout" overlay. This overlay looks like a real payment form. It includes payment and billing fields, client-side card validation, and polished styling to reassure victims. After collecting payment details, the malware silently redirects the shopper to the real checkout page. Victims often remain unaware that their card data was stolen.

Researchers say the skimmer uses several layers of obfuscation and evasion. After collecting payment data, it serializes the information into JSON, XOR-encodes it with the key "script," then base64-encodes the result. It sends this data to attacker-controlled infrastructure disguised as Facebook analytics endpoints. Exfiltration happens via fetch() POST requests in no-cors mode. If this fails, it uses a hidden-iframe fallback. The malware also sets a localStorage flag to avoid re-harvesting from the same victim. This reduces anomalies that could alert users or defenders.

The campaign's infrastructure suggests a coordinated operation rather than opportunistic skimming. Sansec identified six exfiltration domains tied to the campaign. All resolve to the same hosting provider and have identical collection endpoints. Researchers believe the mass infection comes from ongoing exploitation of unpatched PolyShell stores. This suggests attackers have automated both exploitation and skimmer deployment.

This campaign shows how Magecart tradecraft has evolved. Payment skimming groups have always adapted quickly to new defenses. Now, they use SVG onload handlers to hide skimmers, a big leap in stealth. This tactic blurs the line between code and passive web assets. It exploits the fact that SVG files can be both images and XML markup that allows scriptable event handlers. Defenders who treat image assets as safe may miss these hidden payloads.

For Magento and Adobe Commerce operators, the PolyShell crisis underscores the risks posed by delayed patching and complex hosting environments. Adobe released a fix for the issue in pre-release 2.4.9 builds. Production-ready patches were not immediately available when the vulnerability became public. This left many organizations exposed during the early stages of exploitation. To make things worse, Sansec found that most Magento stores have web server configurations that can lead to RCE or account takeover.
Security teams defending Magento environments should respond with urgency.

Recommended defensive actions include:

• Restricting or fully blocking public access to the pub/media/custom_options/ upload directory and validating that web server rules enforce those restrictions properly.
• Conducting compromise assessments for unauthorized file uploads, web shells, suspicious SVG elements, modified CMS blocks, and injected JavaScript across store templates.

Beyond immediate fixes, organizations should rethink how they watch for client-side threats. Traditional server-side malware scanning may no longer detect skimmers hidden in HTML, SVG, or front-end components. Effective detection now needs browser-side integrity monitoring, DOM analysis, and closer inspection of checkout workflows. These steps help detect threats that appear only in the user's browser.

This campaign also shows a new strategy. Attackers now tie initial access exploitation directly to monetization. Instead of selling access or staying long-term, attackers exploiting PolyShell move directly to revenue generation by deploying payment skimmers within hours of compromise. This rapid model shows the efficiency of modern Magecart groups. They increasingly automate the management of exploitation, deployment, and exfiltration.

Magento merchants face patching challenges and complex infrastructure. Attackers will likely keep targeting vulnerable environments. The combination of unauthenticated exploitation, automation, and evasive skimming payloads has turned PolyShell into a full-scale e-commerce crisis.

The lesson for defenders is clear. Modern web skimming campaigns no longer rely on visible JavaScript or basic injection methods. Attackers now use browser features and overlooked markup formats to embed malware that traditional detection rarely checks. With PolyShell and the SVG skimmer campaign, the result is a stealthy, scalable, and financially damaging attack chain. Any Magento store that is slow to patch or poorly monitored is at risk.

Unless organizations patch more aggressively and improve visibility into both server-side and client-side web assets, campaigns like this will continue to expose payment data at an industrial scale.