PolyShell the massive exploitation that threatens Magento and Adobe Commerce and how to protect your online store now

Online store operators using Magento Open Source and Adobe Commerce version 2 face a real and widespread threat: in recent weeks there has been a massive exploitation of a critical vulnerability known in the community as "PolyShell." According to the security investigation team of eCommerce Sansec, the attacks went from being timely evidence to an active campaign within days after the failure was made public, and today they affect a significant portion of vulnerable stores.

PolyShell takes advantage of a weakness in the Magento REST API that allows file uploading within the custom cart options. That load channel can accept "polyclot" files - files designed to be interpreted in different ways by the server and the browser - which in certain server settings allows you to run code remotely or inject persistent scripts (stored XSS) that facilitate the accountability or the injection of malware into the payment pages. Sansec researchers have detailed the technique and maintain a public analysis of how these attacks occur: technical analysis of Sansec.

The scale of the problem is worrying: Sansec indicates that mass exploitation began around March 19 and since then have identified malicious activity in more than half of the stores that are still vulnerable. The firm has also published commitment indicators and a list of IP addresses used by attackers to scan sites for entry doors, useful information for response teams and security providers who want to block suspicious traffic or detect intrusion attempts.

Adobe reacted by releasing a patch in a beta version of the product (branch 2.4.9-beta1) on March 10, 2026, but that correction was not yet available in the stable version at the time of the reports, leaving many production facilities without an immediate official solution. Adobe documented the changes and notes of the version on its Experience League portal: notes to version 2.4.9-beta1. Meanwhile, researchers and journalists have tried to obtain clarification about the patch deployment schedule in the production branches.

What makes the picture even more complicated is the nature of malware that some attackers are installing after exploiting PolyShell. Sansec has found a payment card skimmer using Web Real-Time Communication (WebRTC) as a channel to extract data. Using WebRTC allows attackers to transmit information on UDP via DTLS rather than HTTP, making it difficult for content policy-based controls (CSP) to detect or block exfiltration. The malicious charger is a very light JavaScript that sets a connection to a command and control server (C2) using a forged SDP exchange, receives a second encrypted stage and runs it in the context of the page. To increase its chances of evading detections, the component delays its execution with techniques such as requestIdleCallback and reuses legitimate scripts nonces or uses more risky techniques such as unsafe-eval or direct injection of scripts when necessary.

Sansec even documented the presence of this skimmer in the online store of a large car company, with a market value of over $100 billion, and warned that some notifications to the victims may not have received a response. Sansec's report with the technical split of the skimmer and the IP addresses involved is available here: WebRTC skimmer - Sansec.

What can store managers and security teams do? Although the only final solution is to apply the official patch as soon as Adobe incorporates it into the stable branch, there are palliative measures that reduce the risk. Among the urgent actions is to review and tighten the web server settings to prevent uploaded files from running, restricting or disabling file loads from non-essential locations and to monitor the REST API endpoints that manage cart options. It is also recommended to use the commitment indicators that Sansec has made available to detect automated scanners visits and block malicious IP addresses at perimeter level. It is not necessary to rely solely on CSP policies for this type of WebRTC-based threats, so security teams should be complemented by network output controls and front-end behavior analysis.

The lesson is clear: eCommerce platforms are a privileged target for credentials and skimmers thieves because a single commitment can result in massive loss of payment data and reputational damage. Keeping up with patches, monitoring transaction anomalies and responding soon to the commitment indicators published by research groups dramatically increases the likelihood of detecting and mitigating these incidents before they cause severe damage.

For those who want to deepen the technical details and obtain the published IPs and IoCs lists, Sansec's report on PolyShell and WebRTC's skimmer are recommended resources: PolyShell - Sansec and WebRTC skimmer - Sansec. And to know the state of the official patch by Adobe, you should follow the notes of the version on your portal: notes to version 2.4.9-beta1.

If you run a Magento-based store or work on one's security, don't wait for the explosion to appear in your records: it prioritizes risk assessment and the implementation of compensatory controls right now. This is not a theoretical vulnerability: the attack is under way and the bad actors are already using it to steal customer data and set up automated campaigns against unprotected stores.