PolyShell Vulnerability Hits 57 Percent of Vulnerable Magento Stores as Mass Exploitation Escalates Without a Production Patch
A critical unauthenticated file upload flaw in Magento and Adobe Commerce, dubbed PolyShell, has been exploited at scale since March 19 with no production patch available.
Overview
A critical vulnerability in Magento Open Source and Adobe Commerce, codenamed PolyShell by Dutch e-commerce security firm Sansec, has escalated from disclosure to mass exploitation in under a week. As of March 24, attacks have been observed on 56.7 percent of all vulnerable stores, with attackers deploying payment skimmers, webshells, and backdoors. Adobe addressed the flaw in a pre-release branch but has not issued a patch for production versions of the software, leaving an estimated hundreds of thousands of online stores exposed.
What We Know
The vulnerability resides in Magento’s REST API, which accepts file uploads as part of custom options for cart items. According to Sansec’s technical analysis, when a product option has the type “file,” Magento processes an embedded file_info object containing base64-encoded file data, a MIME type, and a filename, then writes the file to pub/media/custom_options/quote/ on the server. Three missing security controls make this exploitable: no validation of option IDs against actual product options, no file-type enforcement regardless of product configuration, and no file extension restriction beyond a trivial image header check.
Attackers exploit this by uploading polyglot files — data crafted to function simultaneously as a valid image and as executable PHP code — through unauthenticated guest cart endpoints. Depending on the web server configuration, the result is either remote code execution or account takeover via stored cross-site scripting. The vulnerable code has existed since Magento 2’s initial release, according to Sansec.
The timeline of exploitation moved quickly. Sansec first detected probing activity on March 16 and activated protections the same day. By March 19, automated mass scanning had begun, with more than 50 unique IP addresses participating in attacks. By March 24, 56.7 percent of all vulnerable stores had been targeted with malicious PHP uploads, as reported by BleepingComputer.
A separate but related campaign discovered by Sansec’s forensics team revealed that attackers are using PolyShell as an entry point to deploy a novel payment card skimmer that communicates over WebRTC data channels. Unlike traditional skimmers that exfiltrate stolen card data over HTTP, this variant establishes an RTCPeerConnection using DTLS-encrypted UDP, which bypasses Content Security Policy directives entirely. CSP’s connect-src directive controls fetch, XHR, and WebSocket connections but does not restrict RTCPeerConnection, rendering even strict CSP configurations ineffective against this technique. The WebRTC skimmer was found on the e-commerce site of a car manufacturer valued at over 100 billion dollars, according to Sansec. The company did not respond to Sansec’s notification.
What We Don’t Know
Adobe released a beta fix in version 2.4.9-beta1 on March 10, addressing the flaw under security bulletin APSB25-94, but as of March 25, no standalone patch exists for current production versions of Magento Open Source or Adobe Commerce, according to BleepingComputer. Adobe has not publicly commented on when a production patch will ship. It remains unclear how many of the compromised stores have had payment skimmers installed versus simpler defacement payloads, and the full scope of consumer data exposure is not yet known.
The identity of the threat actors behind the mass exploitation campaign has not been disclosed. A related defacement campaign that began on February 27 hit approximately 7,500 domains and 15,000 hostnames, including infrastructure associated with global brands and government services, but its connection to the payment skimmer operators has not been confirmed.
Analysis
PolyShell represents a particularly dangerous class of vulnerability: an unauthenticated, remotely exploitable flaw in widely deployed e-commerce software with no production patch available. The gap between Adobe’s pre-release fix on March 10 and the onset of mass exploitation on March 19 left administrators in an untenable position — aware of the risk but unable to apply an official remediation.
The WebRTC skimmer technique adds a second layer of concern. Payment card skimming has long relied on JavaScript injection and HTTP-based exfiltration, both of which modern Content Security Policies were designed to block. By shifting to WebRTC data channels, attackers have found a protocol-level blind spot in one of the web’s most important client-side security mechanisms. Until browsers standardize and sites deploy a webrtc CSP directive — something that remains experimental in Chrome and absent elsewhere — this evasion technique is likely to spread beyond Magento.
Store operators running any stable version of Magento 2 or Adobe Commerce should restrict web server access to pub/media/custom_options/ directories immediately, scan for uploaded webshells and backdoors, and monitor for the indicators of compromise published by Sansec, including the C2 IP address 202.181.177.177 on UDP port 3479.