{"id":10227,"date":"2026-03-20T16:28:48","date_gmt":"2026-03-20T16:28:48","guid":{"rendered":"https:\/\/plumrocket.com\/blog\/?p=10227"},"modified":"2026-03-20T16:34:01","modified_gmt":"2026-03-20T16:34:01","slug":"polyshell-magento-vulnerability","status":"publish","type":"post","link":"https:\/\/plumrocket.com\/blog\/polyshell-magento-vulnerability","title":{"rendered":"PolyShell: A New Vulnerability in Magento & Adobe Commerce"},"content":{"rendered":"\n

A new Magento vulnerability called PolyShell<\/strong> has been publicly disclosed, affecting nearly all production versions of Magento 2 and Adobe Commerce. This flaw allows attackers to upload files that can execute malicious code on your server \u2014 and no login or account is required to attempt an attack.<\/p>\n\n\n\n

At Plumrocket, we are committed to keeping our clients and the wider Magento community informed and protected. In this article, we explain what PolyShell vulnerability is, how it works, which versions and server setups are at risk, and the immediate steps you should take to secure your store before an attack occurs. If you need help or suspect your store may be at risk, contact us<\/a> \u2014 our team will assist you immediately.<\/p>\n\n\n\n

What Is PolyShell and How Did This Magento Vulnerability Happen?<\/h2>\n\n\n\n

A new security vulnerability in Magento and Adobe Commerce was publicly disclosed on March 17, 2026. Named PolyShell, it allows attackers to upload executable files to any store through the REST API \u2014 without needing an account or login. No production patch exists yet, and the exploit method is already circulating.<\/p>\n\n\n\n

The vulnerability exists in the Magento REST API \u2014 the part of your store that handles behind-the-scenes communication between different systems. Attackers can exploit a flaw in how the API processes file uploads to upload a special file that disguises itself as an image but actually contains executable code. This technique is called a polyglot \u2014 a file that is simultaneously a valid image and a valid program.<\/p>\n\n\n\n

The most serious aspect: attackers do not need a login or an account to do this<\/strong>. Anyone on the internet who knows the technique can attempt to upload the file to your store.<\/p>\n\n\n\n

This vulnerability has existed in Magento since the very first release of Magento 2. It went undetected for years.<\/p>\n\n\n\n

No official patch exists yet for production stores<\/strong>
<\/span>Adobe has fixed this in a pre-release version of Magento (2.4.9-alpha3+), but has not yet released an isolated patch for the versions that almost all live stores run today.<\/p>\n\n\n\n

How Does the Attack Work?<\/h2>\n\n\n\n

When a customer adds a product to their cart, Magento allows them to upload a file as part of a product’s customization options \u2014 for example, a photo for a custom-printed mug. Magento is supposed to accept only image files and save them safely.<\/p>\n\n\n\n

PolyShell exploits the way Magento validates these uploads. An attacker crafts a file that passes Magento’s image check \u2014 it looks like a valid image \u2014 but is also a runnable script. When saved to the server and later accessed through a browser, the server may execute it as code rather than serve it as an image.<\/p>\n\n\n\n

What Can Attackers Actually Do?<\/h2>\n\n\n\n

Depending on your server’s configuration, the consequences range from bad to catastrophic:<\/p>\n\n\n\n

\n
\n

Full remote code execution<\/strong>
On many server setups, an attacker can run any code on your server \u2014 accessing databases, reading customer data, and installing backdoors for persistent access.<\/p>\n<\/div>\n\n\n\n

\n

Account takeover (admin & customer)<\/strong>
Via stored cross-site scripting (XSS), an attacker can hijack administrator and customer sessions, gaining full control of your store.<\/p>\n<\/div>\n<\/div>\n\n\n\n

\n
\n

Silent backdoor installation<\/strong>
Even if code cannot run today, the file stays on your server. A future change \u2014 a server migration, a config update \u2014 can activate it weeks or months later.<\/p>\n<\/div>\n\n\n\n

\n

Payment data theft<\/strong>
Attackers with server access can install skimmers that silently capture customer payment details at checkout \u2014 a major compliance and liability risk.<\/p>\n<\/div>\n<\/div>\n\n\n\n

Is Your Store Affected?<\/h2>\n\n\n\n

The short answer: if you run any production version of Magento Open Source or Adobe Commerce, your store is potentially vulnerable<\/strong>. The table below outlines the specific risk level based on your setup:<\/p>\n\n\n\n

\n
\n \n\n \n \n \n \n \n
\n Vulnerability Type <\/th>\n \n Affected Versions \/ Setup <\/th>\n \n Risk Level <\/th>\n <\/tr>\n
\n Unrestricted file upload <\/td>\n \n All Magento Open Source & Adobe Commerce versions up to 2.4.9-alpha2 <\/td>\n \n High <\/td>\n <\/tr>\n
\n Stored XSS <\/td>\n \n All versions before 2.3.5, or any store with a custom server configuration <\/td>\n \n Elevated <\/td>\n <\/tr>\n
\n Remote code execution (RCE) via PHP upload <\/td>\n \n Stock Nginx on 2.0.0\u20132.2.x (via crafted filenames).\n\nAny Nginx configuration that passes all .php files to FastCGI.\n\nApache versions before 2.3.5 without proper PHP execution restrictions. <\/td>\n \n Critical <\/td>\n <\/tr>\n
\n Patched versions <\/td>\n \n Shipping labels and delivery tracking <\/td>\n \n Fixed <\/td>\n <\/tr>\n <\/table>\n<\/div>