PHP2Shell: why WhizzyCommerce shops are not affected

PHP2Shell is the name given to two bugs in PHP itself, CVE-2026-109618 and CVE-2026-109619, each rated 9.2 out of 10. According to Sansec, every PHP version since 5.4 (2012) is affected, under both Apache mod_php and PHP-FPM, in their default settings. The attack is a crafted upload request that PHP parses before the shop's own code even starts, so a perfectly patched Magento, WordPress or Shopware is just as exposed as a neglected one.

Two things make it worse than usual. Maintenance mode does not help, because PHP reads the request before the application checks the flag. And besides running code, the flaw can leak memory from earlier requests: passwords, session tokens, API keys, even TLS private keys. PHP's own advisory says there is no complete mitigation and updating is the only full fix. Exploitation in the wild was reported within hours.

WhizzyCommerce does not use PHP. Not in the shops, not in checkout, not in the dashboard. A bug in the PHP engine has nothing to run on.

There is nothing for you to do. No update to install, no setting to change, no keys to rotate because of this. Servers, security updates and the software behind every shop are our job, which is the point of a hosted platform: the next engine-level bug, whatever language it lands in, is ours to patch, not yours.

1. 1

   Update PHP now

   The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Updating Magento or your plugins does not help; it is PHP itself that has to change. On managed hosting, ask your host to confirm the version in writing.

2. 2

   On PHP 8.1 or older, plan the jump

   Older releases get no fix. That usually means upgrading the shop software too, so start today, and protect the server in the meantime with the next step.

3. 3

   Until you can update, block uploads at the web server

   Sansec suggests rejecting multipart/form-data requests in nginx or Apache, or serving only GET and HEAD. Both break forms and file uploads, so test checkout afterwards. Turning on the application's maintenance mode is not enough.

4. 4

   Assume secrets may have leaked

   If the server ran an unpatched PHP from 20 October onwards, change the database and admin passwords, rotate payment and API keys, and consider replacing the TLS certificate. Look for PHP files you do not recognise in writable folders such as pub/media.

5. 5

   Remove leftovers

   Old install scripts, test tools and one-off importers left in the web root are the first things attackers call once they can run code. If you ran our Magento connector, make sure pub/whizzy/import.php has been deleted.

Plenty of merchants patch PHP this week and decide it is the last time. If that is you, this is what a move to WhizzyCommerce looks like. No PHP to patch afterwards, no server, no security updates on your list: that part is ours.

Ask on switching from Magento and we write back within a working day. Before the move, read how to leave Magento without losing your Google rankings, and if your release is losing support anyway, Magento 2 end of life.

• Done for you, free. For the first 100 shops moving from Magento, a person on our side runs the move, checks what came across and hands you a shop ready to open.
• The whole shop comes across. Categories, products with their variants and pictures, customers, orders and promotions. Customers set a new password the first time they sign in, and orders arrive as history, with nothing to fulfil or refund.
• A dry run first. The importer shows what it will bring before it writes anything, and it is one file on your Magento that you delete afterwards.
• Your Google rankings stay. Old product and category addresses move on to the new pages with 301 redirects, Magento's own redirects included.
• Free until you sell. No monthly fee on the Free plan; you pay a small fee only when an order comes in.