PolyShell: Mass Exploitation of Magento Hits 56.7% of Vulnerable Stores Before a Patch Exists

Commissioned, Curated and Published by Russ. Researched and written with AI.

What’s New This Week

Mass exploitation of the Magento PolyShell vulnerability is underway. Sansec observed attacks against 56.7% of all vulnerable stores, with more than 50 attacker IP addresses active since March 23. A linked WebRTC-based payment card skimmer has been found on the e-commerce site of a car manufacturer valued at over $100 billion. No patch exists for any production version of Magento or Adobe Commerce.

Changelog

Sansec published its PolyShell research on March 17, 2026. Two days later, mass exploitation began. By March 23, more than 50 IP addresses were probing vulnerable stores. As of today, 56.7% of all vulnerable Magento installations have been targeted.

There is no patch for any production version of Magento Open Source or Adobe Commerce.

The Vulnerability

The bug is in Magento’s REST API. When adding items to a guest cart, the API accepts file uploads as part of cart item custom options. The endpoints are unauthenticated:

• POST /V1/guest-carts/:cartId/items
• PUT /V1/guest-carts/:cartId/items/:itemId

Three validations are absent. There is no option ID check, no option type gate, and no file extension restriction. An attacker can upload .php, .phtml, or .phar files directly to the server via a guest cart request that requires no account, no login, and no session token.

The only guard is an image header check using PHP’s getimagesizefromstring. It is trivially bypassed. Prepend valid image bytes to a PHP payload and the check passes. This is why Sansec named the attack PolyShell: the payload is a polyglot – code disguised as an image.

The vulnerable code has existed since the first Magento 2 release.

GraphQL mutations use a different code path and are not affected. REST API users are.

Adobe fixed the issue in 2.4.9-alpha3, tracked as APSB25-94. That fix was included in a pre-release beta on March 10, 2026. No isolated patch for stable production versions exists.

Uploaded Files Go to a Predictable Location

Uploaded files land in pub/media/custom_options/. If the web server is configured to execute PHP files in that directory, an attacker has remote code execution. If the web server blocks execution, the file still sits on disk. Uploaded files are not removed when the cart is abandoned or the session expires. That means an execution block today is not a permanent defence – the file remains available if configuration changes or another bug emerges.

The WebRTC Skimmer

Some PolyShell attacks are deploying a payment card skimmer that is technically novel in how it exfiltrates data.

Standard Magecart-style skimmers send stolen card data over HTTP or HTTPS. Content Security Policy (CSP) blocks unauthorised HTTP requests via the connect-src directive. This is a standard defence that most security teams rely on.

This skimmer uses WebRTC instead.

WebRTC uses DTLS-encrypted UDP, not HTTP. The connect-src directive in CSP does not cover WebRTC connections. The skimmer’s JavaScript loader connects directly to a hardcoded command and control server using WebRTC, bypassing normal signaling by embedding a forged SDP exchange. Once the channel is open, it receives a second-stage payload over the encrypted connection.

Executing that payload without triggering CSP requires bypassing script injection restrictions. The skimmer attempts three approaches in sequence: reusing an existing script nonce from the page, falling back to unsafe-eval, and finally direct script injection as a last resort. Execution is delayed using requestIdleCallback to reduce the likelihood of detection by monitoring tools that watch for synchronous activity during checkout.

The skimmer was found on the e-commerce website of a car manufacturer valued at over $100 billion. Sansec notified the company. The company did not respond.

Timing strongly suggests the access was gained through PolyShell.

Mitigations

No official patch exists for any production release. These are the options available now.

Block execution in the upload directory. Verify that your web server denies execution of all files in pub/media/custom_options/. For nginx, this means a deny all location block that is not overridden by a downstream .php$ regex rule – order matters in nginx configuration. For Apache, verify that an .htaccess file is present and effective in that directory. This does not prevent uploads. It prevents execution of what is already there.

Block the upload itself. Only a WAF rule targeting the REST API cart endpoints stops the upload from reaching disk. Sansec has published a list of attacker IP addresses for blocking, but IP blocking alone is insufficient given that more than 50 addresses have been observed and the list will grow.

Audit what is already on disk. If your store has been publicly accessible without the execution block in place, check pub/media/custom_options/ for unexpected files. The window between the March 17 disclosure and March 19 mass exploitation is short. The window between Magento 2’s first release and now is not.

Monitor CSP for WebRTC gaps. If your threat model includes skimmers, CSP alone does not cover WebRTC exfiltration. Network-level monitoring of UDP traffic from the browser environment is not straightforward, but script inventory and nonce management reduce the skimmer’s fallback options.

Sansec Shield has blocked exploitation attempts against 23% of all protected Magento stores since March 16.

The practical reality for any team running Magento in production: the attacker needs one successful upload during a window when execution is possible. The defender needs to have closed that window before the first probe. Given that probing started at 12:00 UTC on March 16 – one day before the public Sansec write-up – that window was open for stores that were not already monitoring their upload directories.

The WebRTC exfiltration technique is the detail worth watching beyond Magento. CSP is a mature, widely-deployed defence. Skimmers that route around it entirely via WebRTC channels represent a meaningful escalation in the technical sophistication of e-commerce attacks. Any platform running checkout flows should understand that connect-src in CSP does not cover all possible exfiltration paths.