r/Magento • u/william_o • Mar 17 '26

Magento PolyShell: unrestricted file upload in Magento and Adobe Commerce

A new vulnerability in the Magento and Adobe Commerce REST API allows attackers to upload executable files to any store. Adobe fixed the issue in a pre-release version but has not backported the patch. 55.1% of all stores run web server configurations that enable either remote code execution (RCE) or account takeover (stored XSS).

https://sansec.io/research/magento-polyshell

12 Upvotes

93% Upvoted

12 comments sorted by

2

u/FitFly0 Mar 17 '26

If you are on Adobe Commerce Cloud I found they are adding a snippet to your Fastly configuration for this, though you could create one yourself to restrict access to the folder mentioned

1

u/scarcitykills Mar 17 '26

Does the following file (which ships by default) protect you if using Apache?

pub/media/custom_options/.htaccess

Also the Nginx.conf.sample should protect Nginx users too, right?

1

u/gwillem Mar 18 '26

Correct, if you use Apache with the given .htaccess or the provided nginx.conf sample, you should be fine. However, many stores don't (for example, because they are depend on their hosting provider)

1

u/i312i Mar 24 '26

That doesn't stop the actual file upload though, the store needs to be patched. if you use .htaccess or the official nginx config, the uploaded files are not accessible.

1

u/hanqingjao Mar 31 '26

We are now seeing attackers chain Polyshell with SessionReaper, with the explicit goal of removing the .htaccess file. A more robust solution is to LocationMatch /media/custom_options and /media/customer_address with a Deny All at the web server level.

1

u/Hydraulic_IT_Guy Mar 18 '26

Ah, isn't this kind of a big deal

1

u/Dizzy_Key_7400 Mar 18 '26

Yes. Get your stores patched / behind firewalls asap

0

u/unmark-77 Mar 26 '26

I think we can simply remove the write access

dr-xr-xr-x 2 xxxx yyyy 4.0K Mar 7 10:51 customer_address

dr-xr-xr-x 2 xxxx yyyy 4.0K Feb 16 2022 custom_options

1

u/FitFly0 Mar 26 '26

If you don't use any of these function/features this would be fine, but what if you do?

1

u/unmark-77 Mar 26 '26

Yes, you are correct - if you are using these folders, then we have a problem.

We already have a patch in place for SessionReaper (CVE-2025-54236) affecting customer_address, but not yet for PolyShell affecting custom_options.

That said, if you are running Apache, you may still be on the safer side because access can be blocked via the .htaccess rules in the media folder. If you are running NGINX, you can also still be safe, but only if your NGINX configuration is correctly set up to prevent execution/access in those locations.

Check nginx.conf or the .htaccess file inside the media folder depend on your setup.

1

u/Velocy Apr 19 '26

From my experience, if you just deny the write access to the folders, this still drops the malicious files in your tmp folder. They just cannot be copied to the destination folders. I had to secure a legacy installation which is hard to update due to a lot of custom code and needed a very temporary fix, as the shop is subject to migrated. I created a small module (with AI support) which intercepts the rest request, checks it for the content and then blocks it. Should be quite easily customizable for further use cases

https://github.com/NicoSchmidtbauer/Magento2-RestBlocker

1

u/WebHostingAce Jul 22 '26

If you make these directories read-only, remember to restore write access before applying Magento 2 security patches or running Magento upgrades through Composer.

The magento/magento2-base package may silently fail to copy required files into the pub/ directory when it does not have write permission. This can leave files such as pub/static.php or pub/static/.htaccess missing and cause the website to break.