On 21 October 2026, the PHP team published a critical security advisory: two flaws (CVE-2026-109618 and CVE-2026-109619) that let a stranger run code on a server without needing a password. The press is calling them “PHP2Shell”. That name is not official, but you will see it around.
Does it affect you? If your website runs on WordPress or WooCommerce, yes, as long as the PHP on your server is not patched. And this is the part that confuses people most: a WordPress, WooCommerce or plugin update does not fix it. The flaw is in PHP, the engine underneath. WordPress.org puts it plainly: no WordPress update is required or planned for these issues.
There are real attack attempts. Several security companies confirm it, as does INCIBE-CERT, Spain’s national cybersecurity response team (advisory INCIBE-2026-762, rated “critical”), which reports attacks against PHP servers before the updates existed.
What there is not, as of today, is any documented mass hacking of WordPress sites. Wordfence counted more than 74,000 blocked attempts and, as of 22 October, no confirmed compromise. Other analysts, such as Sansec, believe the public exploits do not work against a default PHP installation. Even so, no serious source considers a website with unpatched PHP to be safe.
Which versions are fixed
PHP released the patch on 21 October. These are the versions that include it:
| PHP branch | Fixed version |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
| 8.1, 8.0 and 7.4 | No official release. Given how serious the issue is, PHP has published source code patches (“backports”) |
| 7.3 and earlier | No fix from the PHP project |
Note the “no official release”. The fact that PHP is not shipping a new 8.1 version does not mean your hosting cannot protect you. More on that below.
How to check your PHP version (and why the number can mislead you)
First, find out what you have:
- Log in to WordPress and go to Tools > Site Health > Info > Server. The “PHP version” is listed there.
- Or open your hosting control panel, usually in a section called PHP.
- From the outside, with our free Check my hosting tool: if your server announces its PHP version, it shows it and tells you whether it is older than the fixed ones. Bear in mind that most hosts hide it, which is the recommended practice, and no online checker can see the version if the server does not announce it. In that case, use step 1 or 2.
Now for the catch. Many hosts and Linux distributions apply the patch without changing the version number. This is what is known as a backport. A site showing 8.5.11, or even 8.1.x, may be fully fixed. And the other way round: a “modern” number proves nothing if the server has not been updated and restarted.
That is why the number on its own is not enough. You have two ways to be sure:
- Check the build date. GoDaddy and Hostinger explain that, if your panel shows the “Build Date” (for example in PHP Info), it must be 21 October 2026 or later. If it is earlier, it is not patched.
- Ask your hosting provider in writing. This is the most reliable option if you are not technical. Wordfence suggests asking something like this:
Is the PHP serving my website patched against CVE-2026-109618 and CVE-2026-109619, and has PHP been restarted?
The restart matters: a patch that is installed while the old processes are still running does not protect you.
If you have access to the server: the php -v you see in the terminal may not match the PHP that serves the website (both Sucuri and Wordfence warn about this).
What to do depending on your type of hosting
This is the difference that matters most and is explained least.
Shared or managed hosting
The provider patches the server for you. This is what they say themselves, as of 25 October:
- SiteGround: patches applied on all servers on 21 October. They say you do not need to do anything.
- Hostinger: patching completed on 22 October on everything except VPS. No action required either, except on VPS.
- GoDaddy: managed WordPress patched on 21 October; web and Windows hosting on the 22nd. No action required, except on VPS.
- IONOS: says it has already installed the official updates, without giving a date. For versions managed from your account, no action is required. On VPS and dedicated servers, yes, immediately.
If your provider is not on the list, do not assume it is patched: I have not found a statement from all of them. Ask them using the question above and keep their reply.
In this case, you do not need to switch PHP branch to get the patch. The provider fixes whichever one you have. Being on an unsupported version is a different matter, which we cover further down.
VPS, dedicated server, or your own Plesk/cPanel
Here the patch does not arrive on its own. If you have a VPS (with IONOS, OVH or anyone else), it is your responsibility or that of whoever manages it for you.
What the sources say:
- Plesk: fixed versions of PHP 8.2 to 8.5 are available. Backports for 7.4 to 8.1 were “in testing” according to its forum, and that may have changed. Update from Tools & Settings > Updates (the exact path depends on your Plesk version; I have not checked it against the official documentation).
- cPanel/WHM: according to Patchstack, there are fixed ea-php packages from 5.2 to 8.5. The administrator installs them from EasyApache 4. I have not found the official cPanel announcement.
- After updating: restart all PHP processes.
If you cannot update today, PHP describes partial mitigations, but insists that only updating is a complete solution. This is sysadmin territory: if you do not know what an FPM pool is, leave it to someone who does.
And a warning: a firewall such as Cloudflare or Wordfence helps, but it is no substitute for the patch. Part of the attack happens before WordPress starts, and if someone reaches the origin server directly, the WAF has no say in the matter.
How to update PHP without breaking your website
There are two separate decisions, and it is best not to mix them up:
- Patch now. This is urgent, and on managed hosting the provider does it.
- Switch PHP branch (for example, from 8.1 to 8.4). This is a planned decision, with a backup and testing.
If you need to do the second, follow the steps from WordPress.org:
- Make a full backup (files and database).
- Update WordPress, your theme and your plugins, and check that everything works.
- Check compatibility with the PHP Compatibility Checker plugin. Note that its own authors warn it is not perfect and can miss things.
- If a plugin is incompatible, contact its developer or look for an alternative.
- Change the version in your hosting control panel.
- If something breaks, go back to the previous version or restore the backup.
If you can, do step 5 first on a copy of the website (a test or staging environment). WordPress.org does not mention it on that page, but it is what I would do with a shop that takes payments.
WordPress 7.0 and 7.1 are compatible with PHP 7.4 to 8.5. The problem is almost never the core: it is old plugins and themes.
What to test afterwards (especially on WooCommerce)
A 500 error or a blank page right after the change usually points to an incompatible plugin. Go back to the previous version and find out which one it is. If everything loads, check:
- Access to the admin dashboard.
- A complete test order: add to basket, checkout and payment with your payment gateway.
- Order and contact emails.
- Forms and file uploads.
- Scheduled tasks (cron) and any connection with other services (APIs).
- The server error log.
This list comes from the recommendations of Sucuri and NEUBOX. The test order is the one check you cannot skip.
The third flaw: CVE-2026-115560
On 23 October, PHP published a third, lower-risk advisory.
It only affects an unusual combination: an application that sets session.serialize_handler to php_binary or php_serialize, changes it to php with ini_set() before session_start(), and has upload progress enabled. It is unlikely to be your case.
The temporary measure PHP recommends is to set session.upload_progress.enabled=0 until the next maintenance release. As of 25 October, there is no version that fixes it and no NVD entry. If your hosting is managed, it is their job; ask them whether they have taken it into account.
PHP release schedule and which version to choose
This is what php.net says as of 25 October 2026:
| Branch | Active support until | Security fixes until | Status today |
|---|---|---|---|
| 8.5 | 31/12/2027 | 31/12/2029 | Active support |
| 8.4 | 31/12/2026 | 31/12/2028 | Active support |
| 8.3 | 31/12/2025 | 31/12/2027 | Security fixes only |
| 8.2 | 31/12/2024 | 31/12/2026 | Security fixes only; end of life in two months |
| 8.1 and earlier | — | — | End of life |
My recommendation, in line with the sources: 8.3 at the very least (what WordPress.org advises) and, if your website supports it, 8.4 or 8.5 (what Patchstack advises). If you are on 8.2, you have until the end of the year. If you are on 8.1 or lower, you are on a branch that no longer receives patches from the project: only your hosting is protecting you, and you should move off it calmly, but soon. 8.6 is at release candidate (RC) stage and is not for production.
Frequently asked questions
Everything is up to date. Isn’t that enough? No. WordPress, your plugins and your theme can all be up to date and the website still be exposed if the server’s PHP is not.
Do I need to take my website or shop offline? Not as a general rule. Sansec states explicitly that there is no need to close a shop. WordPress.org notes one exception: if you run your own server with PHP older than 8.2 and cannot patch it, consider taking it offline while you prepare the update.
Does my security plugin or Cloudflare protect me? They help, but they are no substitute for the patch. Wordfence acknowledges that part of the attack happens before WordPress starts. And be wary of unofficial “fix” plugins or snippets: Patchstack advises against them.
I’m on PHP 7.4, 8.0 or 8.1. Am I unprotected? You are on affected versions with no official patch from the project. What matters is whether your hosting has applied the backports (SiteGround and Hostinger say they have applied them on their servers). Ask, get it confirmed in writing and plan the move to 8.3 or later.
How do I know if I’ve already been hacked?
If your server was left unpatched, check for: administrator users you do not recognise, .php files inside wp-content/uploads, recently modified files and security warnings in Search Console. Wordfence saw attacks that tried to upload a file called wp2s.php and to read wp-config.php and .env. If you find anything odd, restore a backup from before the attacks, change passwords and API keys, and keep the logs: Wordfence recommends keeping backups and logs from 48 hours before 21 October.
So, what now
Three things, in this order: find out whether your hosting is managed or the server is yours; ask in writing whether PHP is patched and restarted; and put a note in your calendar that PHP 8.2 reaches end of life on 31 December.
If you would rather not deal with it, at AGENCIA RSE this is part of our WordPress maintenance: checking which PHP your website runs on, testing changes on a copy and checking the checkout afterwards. But you do not need to hire anyone to follow this guide. With Wordfence’s question and the schedule above, you can sort it out yourself.
If you spot any outdated information, let us know and we will correct it.