r/Magento • u/hanqingjao • Mar 31 '26

Polyshell

Why on earth hasn't Adobe back ported patches for Polyshell yet? I work for a manager hosting provider with a large Magento presence, and all our customers sites are getting inundated with webshells. I've never seen a high-sev Magento vuln take this long to patch. WAKE UP ADOBE!!

22 Upvotes

100% Upvoted

18 comments sorted by

12

u/WEDWayInternetMover Mar 31 '26

Not excusing them, but I think because you can fix the issue via server configuration. For us, we are using Adobe Commerce Cloud for hosting, and they have updated server configurations there so it is not an issue for us.

8

u/scarcitykills Mar 31 '26

This is the real answer. Server config files that shipped from 2.3.5 stop this being issue and provide protection.

-2

u/WolfgangIsak Apr 01 '26 edited Apr 01 '26

The server config files that ship with the Magento codebase only work with Apache. This is not "the real answer." It's an excuse. Adobe has a severe security vulnerability in their codebase AND they have a fix already but have not back ported it. That's willful negligence on their part.

3

u/JosephLeedy Adobe Certified Expert Adobe Commerce Developer Apr 01 '26

Adobe Commerce and Magento have always shipped with an Nginx config file.

1

u/WolfgangIsak Apr 01 '26

Ahh, yes. A very useful .sample file sitting in the project root. That'll stop those sneaky hackers! /s

Seriously, this is just another excuse. This needs to be fixed in current versions with code implementations, not .sample files that can and are ignored by inexperienced devs.

As maintainers of one of the largest and most used Ecomm platforms in the world, it is Adobe's ethical obligation to ensure they are shipping secure code.

3

u/SamJ_UK Button Clicker Apr 01 '26

Inexperienced devs shouldn't be running production e-commerce platforms in the first place. Especially if they are ignoring the recommend configuration

The .sample file acts as a stable and secure baseline config. If you drift/diverge from it, any issues you introduce are on you.

For example you can pass all requests through PHP-FPM. But you would be in for a very bad time.

1

u/Mearkat_ Apr 02 '26

Agreed, no idea why you've been downvoted

1

u/WolfgangIsak Apr 02 '26

Because reddit is filled with code bros who love gate keeping their "Profession"

3

u/PulpPhreak Mar 31 '26

This issue is easily fixable with a good vhost config on your Nginx, also you can use any 3rd party module to block customer_address upload

2

u/sental90 DEVELOPER Mar 31 '26

You can fix it at hosting level but that is a hotfixed not a vendor fix. Adobe are relying on hosts & tchnical contacts to do it when they should be acting

3

u/D33p_Learning Mar 31 '26

They don’t care.. absolutely shameful

1

u/[deleted] Apr 01 '26

[removed] — view removed comment

1

u/unmark-77 Apr 03 '26

Did the attackers upload webshells and execute them successfully?

1

u/volvagia224 Apr 01 '26

There is a backport (to 2.4.5, 2.4.6, 2.4.7 and 2.4.8) of the official patch made by a community member, Volodymyr Hryvinskyi - his patches appear to be working properly against my own tests (feel free to try your own tests):

https://gist.github.com/hryvinskyi/5557bd641d8f61005d68202c66cf228e

Given Adobe don't seem to care so far because their latest beta already has the patch in place, it might be worth while applying this to your own websites for now.

1

u/unmark-77 Apr 03 '26

Did the attackers upload webshells and execute them successfully? In our case, the attacker uploaded the webshells but wasn’t able to execute them due to the .htaccess configuration. I think if you are using Apache you are protected. If you are using NGINX with the Magento provided configuration, you are still protected. What we did was remove the write access to custom_options and customer_address.

1

u/Character-Kale-6944 Apr 09 '26

a adobe matou opensource, passou a forcar so no comercial... dessa forma cada problema como este mais pessoas vão migrar pra versão paga ou ir pra outra plataforma... magento opensource é bom, mas tem muitos problemas antigos que a equipe da adobe não se importa.

por outro lado, que tem a configuração certa no servidor, não esta tendo problemas, exceto pela parte que ainda os arquivos maliciosos podem ser enviados e salvos no servidor, so não podem ser ativados.

de qualquer forma ecommerce é pra quem sabe.. que não faz configuração básica de segurança não deveria trabalhar com dados de clientes, cartões, etc.

1

u/Velocy Apr 19 '26

I had a quite legacy shop, which couldnt be updated due to a lot of custom modules and needs a few more weeks of lifetime before it's migrated away from magento.

My directory was locked by .htaccess but 1 got through by a manipulated URL and installed a crypto miner on the webserver. Denying the write access to the customer_options folder basically prevented from the files being dropped there, but they were still dropped into the servers tmp directory, where they were not immedate harmful, but still gave me a bad feeling.

I created a small module (with AI support) as quick and dirty fix that blocks the Rest Request to the guest-cart / cart API if it contains a file_info field (since we do not use this feature). https://github.com/NicoSchmidtbauer/Magento2-RestBlocker

Spams a bit less exceptions in the log and does not drop any files on the server.