PolyShell: Attackers Are Hitting 57% of Vulnerable Magento Stores With a WebRTC Skimmer That Bypasses Every Content Security Policy

The Story

Dutch e-commerce security firm Sansec disclosed PolyShell last week, naming it for the polyglot technique at its core: attackers upload a file that is simultaneously a valid image and executable code. The vulnerability sits in Magento's REST API, which accepts file uploads as part of cart item custom options. When a product option has type "file," Magento processes an embedded file_info object containing base64-encoded file data, a MIME type, and a filename. The file gets written to pub/media/custom_options/quote/ on the server with insufficient validation.

The impact depends on the web server configuration. On stock nginx configurations for Magento 2.0 through 2.2, or any server passing all .php requests to FastCGI, the uploaded polyglot can execute as PHP, giving the attacker remote code execution. On Apache configurations without the proper php_flag engine 0 directive, the same applies. On stores where PHP execution is blocked in that directory, attackers can still achieve stored cross-site scripting for account takeover. Either path leads to full store compromise.

Adobe addressed the flaw in the 2.4.9 pre-release branch (APSB25-94) on March 10. But the fix has not reached any production version. Every stable Magento Open Source and Adobe Commerce installation through 2.4.8 remains vulnerable. Adobe has not responded to press inquiries about a production patch timeline. BleepingComputer and Sansec both reported they received no response from Adobe.

Mass exploitation kicked off on March 19, with automated scanning accelerating rapidly. Sansec tracked 50+ unique IP addresses participating in the scanning activity and confirmed PolyShell attacks against 56.7% of all vulnerable stores. The first probing was detected on March 16 at 12:00 UTC.

The most advanced attack observed so far targeted a car manufacturer with over $100 billion in revenue. The attacker deployed a novel payment card skimmer that uses WebRTC data channels instead of traditional HTTP requests to load its payload and exfiltrate stolen card data. The skimmer establishes a WebRTC peer connection to a hardcoded C2 IP address (202.181.177[.]177) over UDP port 3479, receives JavaScript code via the data channel, and injects it into the checkout page to harvest payment information.

Why WebRTC matters: Content Security Policy is the primary defense most e-commerce sites use to block unauthorized script execution and data exfiltration. CSP directives like connect-src control fetch, XMLHttpRequest, and WebSocket connections. But CSP does not control RTCPeerConnection. This is a known gap in the CSP specification. Chrome has shipped experimental support for a webrtc CSP directive, but it is not standardized and virtually no site deploys it. For the vast majority of real-world stores, this bypass works. A store with a strict CSP that blocks all unauthorized HTTP connections is still wide open to WebRTC-based exfiltration.

The Adversary Perspective

From a red team lens, this attack chain is elegant in its simplicity and its evasion design.

The initial access vector requires zero authentication. No stolen credentials. No admin panel access. No social engineering. An attacker sends a crafted REST API request with a polyglot file embedded in the cart item options, and the server writes it to a predictable directory. The entire initial compromise can be automated with a single HTTP request per target store.

The WebRTC exfiltration channel is a genuine innovation in the Magecart playbook. For years, payment skimmers have used HTTP requests, image beacons, or WebSocket connections to exfiltrate stolen card data. All of these are subject to CSP enforcement. WebRTC peer connections are not. The attacker found a protocol-level gap in the browser's security model and built a skimmer around it. This is not a CSP misconfiguration. This is a specification gap that affects every site relying on CSP as a defense against Magecart attacks.

The absence of a production patch creates an indefinite exposure window. The fix exists only in a beta branch. Organizations running Magento in production cannot deploy a beta as a security fix. Until Adobe releases a stable patch, every store is either mitigated at the web server level (blocking the upload directory) or vulnerable. Given that Sansec found 56.7% of vulnerable stores already attacked, the attacker population clearly has the exploit and is scaling it.

Defensive Takeaways