PolyShell and Magento 2: why this is a real, urgent threat for store owners

If you run a Magento 2 store, the PolyShell story is not just another security headline to skim and ignore. It is a serious reminder that Magento stores remain high-value targets, and that one weak point in the wrong place can turn into a full storefront compromise, payment skimming operation, or admin takeover. Public reporting around PolyShell shows exactly that pattern: a critical file-upload flaw, very fast weaponisation, mass scanning, real-world compromises, and post-exploitation malware aimed at ecommerce stores.

PolyShell is the name Sansec gave to a flaw in Magento and Adobe Commerce’s REST API. In plain English, the issue lets an attacker upload a malicious file to a store without logging in first. The attack works through cart item custom options: Magento accepts file uploads through a file_info object, writes the file into pub/media/custom_options/quote/, and, according to Sansec’s analysis, fails to enforce three checks that should have stopped the attack earlier: validating the option ID, ensuring the option is actually a file-type option, and blocking dangerous extensions like .php, .phtml, and .phar. The only meaningful content check was an image-header check, which researchers said was easy to bypass with a polyglot file, hence the name “PolyShell.”

That technical detail matters because this is not just “someone can upload junk into media.” Under the right web server configuration, the uploaded file can become a path to remote code execution. In other cases, it can still lead to stored cross-site scripting and account takeover. Sansec said the unrestricted file upload affected Magento Open Source and Adobe Commerce versions up to 2.4.9-alpha2, with stored XSS affecting pre-2.3.5 versions or stores with custom web server configurations, and RCE possible on several nginx and Apache setups. Even when code execution is blocked, the malicious file can remain on disk, meaning a future server migration or configuration change could suddenly turn a previously “harmless” file into an active compromise.

That last point is one reason this is a real issue for Magento 2 owners rather than a theoretical one. A lot of merchants assume that if nothing exploded immediately, they are safe. PolyShell breaks that assumption. It creates the possibility of a planted payload that does not need to fire right away to be dangerous. A store can be compromised quietly, left with attacker-controlled files on disk, and then exposed later when infrastructure changes. That makes the risk operational as well as technical.

The second reason it is real is that exploitation moved fast. Sansec said probing started on March 16, 2026, automated mass scanning began on March 19, and by March 25 BleepingComputer, citing Sansec, reported attacks on 56.7% of vulnerable stores. By March 30, Sansec said it had blocked PolyShell exploitation attempts against 79.5% of protected Magento stores and had seen 471 stores compromised in a single hour. That is not the pattern of an obscure bug sitting in a lab. It is the pattern of an exploit that attackers folded into active operations almost immediately.

The third reason it is real is what happened after access was gained. Sansec’s March 30 write-up described an attack chain in which attackers used PolyShell to upload a PHP webshell, dropped accesson.php backdoors into multiple directories, and then injected obfuscated JavaScript into CMS pages and static blocks. That injected code pulled additional payloads from the freshly registered domain lanhd6549tdhse.top, used localStorage for persistence, and fingerprinted visitors by collecting referrer, title, and query-string data. In other words, the initial foothold was not the end goal. It was a way to get durable access and monetise the store.

For Magento store owners, that monetisation angle is the part that should really land. This is ecommerce-specific crime. The attackers are not just defacing pages for attention. Public reporting tied suspected PolyShell exploitation to a novel payment-card skimmer that used WebRTC DataChannels to receive payloads and exfiltrate stolen data. Sansec said this technique bypasses many normal browser and network controls because WebRTC traffic does not behave like ordinary HTTP requests and can slip past Content Security Policy expectations and HTTP-focused inspection tools. Sansec said it found that skimmer on the ecommerce site of a car maker valued at over $100 billion, which shows that large brands are not magically insulated from this class of compromise.

That leads directly to why Magento 2 merchants should care even if they are not enterprise-sized. Small and mid-market Magento stores often have exactly the conditions attackers like most: public-facing checkout flows, customer accounts, payment data in motion, complex plugin stacks, and custom hosting or web server rules that may have drifted over time. Sansec specifically noted that many stores use custom configurations from hosting providers, and that many exposed files in the upload directory. That means the practical risk is not limited to whether your Magento version number looks current on paper. It also depends on how your stack is actually deployed.

There is also an uncomfortable Magento-specific truth here: stores are rarely compromised by a single mistake alone. The platform’s real-world attack surface is usually a combination of core software, extensions, infrastructure, and operational habits. PolyShell is dangerous because it cuts across those layers. The API behavior creates the opening. The web server configuration can turn that opening into code execution. CMS access gives attackers a place to inject scripts. Weak monitoring lets them stay there. And because the target is an online store, every minute of attacker dwell time can translate into stolen cards, hijacked sessions, malicious redirects, fake checkouts, customer distrust, and expensive incident response. Those business outcomes are an inference from the attack chain Sansec documented, but they are exactly what ecommerce malware campaigns are built to achieve.

Another reason this has felt so alarming in the Magento community is that the public patch story has been messy. Sansec’s initial advisory said Adobe had fixed the issue in the 2.4.9 pre-release branch and that no isolated production patch existed at that point, a view repeated by several media reports. Separately, Adobe’s March 10, 2026 security bulletin APSB26-05 recommended updating supported branches to current versions including 2.4.8-p4, 2.4.7-p9, 2.4.6-p14, 2.4.5-p16, and 2.4.4-p17. So, for merchants, the safe interpretation is simple even if public reporting has been confusing: be on the newest supported security release for your branch, and do not treat version lag as acceptable.

What should a Magento 2 store owner do right now? First, update to the newest supported Adobe Commerce or Magento Open Source security release for your branch. Adobe’s bulletin explicitly recommends moving to the latest versions it lists. Second, harden the upload path. Sansec specifically advised blocking access to pub/media/custom_options/ and checking that nginx or Apache rules are not accidentally allowing uploaded PHP to execute. Third, scan for compromise, not just vulnerability. Sansec’s guidance was clear that merchants should look for uploaded webshells, backdoors, and injected JavaScript, because by the time mass exploitation is underway the question is no longer only “can I be hit?” but also “have I already been hit?”

The broader lesson is that PolyShell is not scary because it has a dramatic name. It is scary because it hits the exact combination that makes ecommerce incidents costly: unauthenticated access, easy automation, persistent payloads, checkout-adjacent systems, and post-exploitation tooling built for skimming and monetisation. When attackers can move from a guest-cart API to server-side foothold to injected frontend malware, that is not a minor bug. That is a business-risk event.

So yes, PolyShell is a real issue for Magento 2 store owners. It is real because it was publicly disclosed with credible technical detail. It is real because exploitation followed quickly. It is real because the payloads seen in the wild were designed for ecommerce theft, not abstract proof-of-concept demos. And it is real because many Magento stores still depend on custom infrastructure and operational shortcuts that make a bad vulnerability much worse when attackers start moving at scale.