PolyShell: A New Vulnerability in Magento & Adobe Commerce
A new Magento vulnerability called PolyShell 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 — and no login or account is required to attempt an attack.
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 — our team will assist you immediately.
What Is PolyShell and How Did This Magento Vulnerability Happen?
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 — without needing an account or login. No production patch exists yet, and the exploit method is already circulating.
The vulnerability exists in the Magento REST API — 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 — a file that is simultaneously a valid image and a valid program.
The most serious aspect: attackers do not need a login or an account to do this. Anyone on the internet who knows the technique can attempt to upload the file to your store.
This vulnerability has existed in Magento since the very first release of Magento 2. It went undetected for years.
No official patch exists yet for production stores
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.
How Does the Attack Work?
When a customer adds a product to their cart, Magento allows them to upload a file as part of a product’s customization options — for example, a photo for a custom-printed mug. Magento is supposed to accept only image files and save them safely.
PolyShell exploits the way Magento validates these uploads. An attacker crafts a file that passes Magento’s image check — it looks like a valid image — 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.
What Can Attackers Actually Do?
Depending on your server’s configuration, the consequences range from bad to catastrophic:
Full remote code execution
On many server setups, an attacker can run any code on your server — accessing databases, reading customer data, and installing backdoors for persistent access.
Account takeover (admin & customer)
Via stored cross-site scripting (XSS), an attacker can hijack administrator and customer sessions, gaining full control of your store.
Silent backdoor installation
Even if code cannot run today, the file stays on your server. A future change — a server migration, a config update — can activate it weeks or months later.
Payment data theft
Attackers with server access can install skimmers that silently capture customer payment details at checkout — a major compliance and liability risk.
Is Your Store Affected?
The short answer: if you run any production version of Magento Open Source or Adobe Commerce, your store is potentially vulnerable. The table below outlines the specific risk level based on your setup:
| Vulnerability Type | Affected Versions / Setup | Risk Level |
|---|---|---|
| Unrestricted file upload | All Magento Open Source & Adobe Commerce versions up to 2.4.9-alpha2 | High |
| Stored XSS | All versions before 2.3.5, or any store with a custom server configuration | Elevated |
| Remote code execution (RCE) via PHP upload | Stock Nginx on 2.0.0–2.2.x (via crafted filenames). Any Nginx configuration that passes all .php files to FastCGI. Apache versions before 2.3.5 without proper PHP execution restrictions. | Critical |
| Patched versions | Shipping labels and delivery tracking | Fixed |
How to Protect Your Magento Store Right Now
There is no official patch from Adobe for production stores yet. Until one is released, here are the three most important steps to take:
1. Restrict access to the vulnerable upload directory
Your web server should deny all access to the directory pub/media/custom_options/. This can be done via Nginx or Apache rules and helps prevent any uploaded malicious files from being executed.
2. Review your server configuration carefully
Default (out-of-the-box) configurations are often more secure than heavily customized ones. Double-check that your setup does not allow .php or other executable files to run inside media directories.
3. Deploy active protection
Use a reliable server-side scanning tool to inspect the custom_options directory and the rest of your environment for suspicious or unknown files. This helps identify whether your store has already been compromised.
If you suspect your store may be affected or need help securing your environment, don’t take chances. Contact us and our team will assess your store and guide you on the next steps.
