To find out whether PHP2Shell affects your site, you need two answers: the exact website PHP version your site runs, and the name of whoever controls PHP on that server. PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 carry the fix, and so do patched builds from hosts and Linux vendors. On shared and managed hosting the host patches PHP. On your own server or VPS, you or your developer do. On Shopify, Squarespace, Wix or Webflow, the platform runs the servers. This guide goes platform by platform. It comes from xCreative™, the Melbourne studio that designs and builds websites, then hosts and maintains them. We spent 22 to 24 October patching and moving the servers behind nearly 100 client websites. That story is in our first article on PHP2Shell.
Start with the version number, then ask who owns PHP
The PHP project’s advisory lists the four fixed releases and says Linux distributions and long-term support vendors received the patches in advance. PHP 8.1 and older get no new releases from the PHP project. Some vendors backport the fix to those versions instead.
That creates a trap. A backported fix can leave the version number exactly as it was. Laravel Forge’s knowledge base says plainly that for patched PHP 8.1 and older, the php -v command reports the same version before and after the update, and the package revision is what proves the fix. So a number like 8.1.34 is not proof either way. Ask the person who installed it.
The command line can also mislead in a second way: the PHP your terminal runs is not always the PHP your website runs. When we checked our own servers on 24 October, we read the live setting from each website itself rather than trusting a config file.
WordPress and WooCommerce, plus Joomla and Drupal
These systems all run on PHP, and none of their own updates can fix a flaw in PHP itself.
- WordPress and WooCommerce. The version is under Tools, then Site Health, then Info, in the Server section, as described in WordPress’s Site Health documentation. A store runs on the same PHP as the rest of the site, so WooCommerce adds no separate check.
- Drupal. The Drupal Security Team’s public service announcement PSA-2026-10-20 says: if you manage PHP yourself, apply the update; if your host manages it, follow the host’s instructions. It also states that site owners are responsible for the security of their hosting platform, and that the team’s remit covers only code hosted on Drupal.org.
- Joomla. We could not find a Joomla project notice about PHP2Shell at the time of writing. The Joomla 4 technical requirements recommend PHP 8.2, and on that branch the fixed release is 8.2.35. Your host or developer can confirm the exact build.
Who patches depends on the hosting, not the CMS. A WordPress site on shared hosting and a WordPress site on its own cloud server look identical in the dashboard, but only one of them has a host doing the PHP work. If we built or maintain your WordPress site, that question already has an answer.
Magento, Adobe Commerce and custom PHP applications
Stores and bespoke systems often involve several people, each assuming someone else has PHP covered.
- Magento and Adobe Commerce. A self-hosted Magento store is patched by whoever runs its server. On Adobe Commerce on cloud infrastructure, Adobe’s documentation shows the PHP version is chosen in the project’s .magento.app.yaml file. Ask your developer and Adobe support, in writing, whether the PHP your store runs includes the 21 October fix.
- Laravel and other custom PHP apps. Booking portals, quoting tools and member areas are often built on a framework such as Laravel. The framework does not decide your PHP. Forge, Laravel’s own server tool, says its automatic security updates do not patch PHP and that you must update PHP on each server yourself. If a developer set up a server for your app and then moved on, nobody may be watching it.
Vercel’s security bulletin puts it bluntly: updating application code or plugins does not fix these vulnerabilities. The runtime has to change. When we take on a custom build through our website design and development work, the handover includes who owns the server, because this is exactly the week that question gets tested.
Shared hosting, managed hosting and your own server
- cPanel or Plesk shared hosting. In cPanel, MultiPHP Manager lists the PHP version each domain uses. In Plesk, Plesk’s documentation says the version shows next to the PHP icon on the domain card. cPanel’s documentation notes that only the system administrator can set the system PHP version. Either way, the host installs the patched packages. CloudLinux, which supplies PHP builds to many cPanel hosts, lists fixed packages and tells server operators to restart Apache and PHP-FPM after updating. Your job is to ask the host for written confirmation that your plan is patched for CVE-2026-109618 and CVE-2026-109619, and the date it was done.
- Managed WordPress hosting. The host owns PHP. For one example, Automattic announced on 21 October that sites on WordPress.com, WordPress VIP, WP Cloud and Pressable were already protected, with nothing for owners to do. If your managed host has not said anything publicly, ask.
- Your own VPS or cloud server. Nobody patches it unless you or your developer do. Update PHP, restart every PHP process, then confirm the version the website reports. Old servers count too. After we moved sites to new servers this week, the retired machines were still taking requests in the thousands over 48 hours, almost all from automated scanners hitting the IP address directly. A forgotten server running old PHP gets found.
Patching is the core of our website maintenance and hosting care: we own the server, so the patch, the restart and the check are ours, and clients get told what was done.
Shopify, Squarespace, Wix, Webflow, static sites and non-PHP stacks
Hosted website builders run their own servers, so PHP patching is not the site owner’s job. Webflow’s security statement says that its core services are not built on PHP, are not affected, and need no action from customers. We could not find a PHP2Shell notice from Shopify, Squarespace or Wix at the time of writing, so check their status pages rather than relying on anyone’s summary.
Static sites and sites built on Node.js, Next.js or similar are not exposed through PHP, because there is no PHP serving them. The catch is what sits around the main site: an old blog on a subdomain, a contact form script on cheap hosting, a staging copy nobody deleted. Any of those can run PHP while the main site does not.
There is a search angle as well. Google reports hacked content in Search Console’s security issues report, and a site carrying injected spam pages loses trust with Google and with AI assistants that cite it. Our SEO and GEO work checks that report as routine, because rankings rest on a clean site. If you are not sure who owns PHP for your website, or you want one team looking after it from design through to search, contact our Melbourne studio and we will tell you where your site stands.
Frequently asked questions
Where do I find my website PHP version without logging in to the server?
In WordPress, go to Tools, then Site Health, then Info, and open the Server section. On cPanel hosting, MultiPHP Manager shows the version per domain if your host allows it. On anything else, ask your host or developer for the exact build, not just the branch.
My host says PHP is patched but the version still reads 8.1. Is that right?
It can be. Fixes backported to PHP 8.1 and older keep the old version number, so the package revision is what shows the patch. Ask the host which package build you are on. PHP 8.1 no longer gets releases from the PHP project, so plan a move to a supported version.
Is my Shopify or Webflow site at risk from PHP2Shell?
Webflow says its core services do not run on PHP and are not affected. Hosted builders manage their own servers, so patching is not your task. Check any separate PHP tools linked to the site, such as a booking app or an old blog on its own hosting.
