php2shell: how fast hosting providers closed the critical PHP vulnerability
On October 21, 2026, the PHP project closed two vulnerabilities that let attackers run code on a server without logging in. They are only really closed once your host installs the update, though. We tracked 27 systems of our own and ones we look after to see when that happened, and we show how to check where you stand.
On October 20, the PHP project announced a critical security release for the next day, at 14:00 UTC. On October 21 at 16:00 German time, PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 were available. What happens after that is, for most website owners, out of their own hands: if you use shared hosting or managed WordPress, you stay open to attack until your host rolls the update out to its servers.
We look after a number of websites and applications at various hosts, our own and our customers'. For 27 of them we noted that evening when the new version arrived. The result is not a hosting test, but an honest look at how much the speed varies.
What php2shell is
According to the PHP project's security advisory, the name stands for two errors in how memory is handled between requests. With CVE-2026-109618, an abort caused by running out of memory can leave data in a half-finished state that PHP treats as valid during cleanup. With CVE-2026-109619, internal state of one request is left behind after its memory has already been freed, and the next request in the same process accesses it. Both are rated CVSS 9.2 and, in the worst case, allow an attacker to run their own code on the server.
Every PHP installation that answers web requests is affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest with mod_php. The attacker needs no login, and the attack takes effect before WordPress or any plugin runs any code at all. A security plugin therefore sees nothing of it.
How far attacks have already gone is judged differently by different sources. The Canadian Centre for Cyber Security reported a public proof of concept on October 21 and 23, but no confirmed exploitation yet (alert AL26-026). According to Help Net Security, Amazon saw an exploitation attempt as early as October 17, four days before publication.
Our measurement: 27 systems, seven hosts and one server of our own
We measured from the outside and read-only. Most hosts state the PHP version in the X-Powered-By response header. We queried it every five minutes at Hostinger and STRATO, on wp-login.php, because that page never comes from the cache and PHP is certain to run. At Raidboxes the version was in the WooCommerce system report. All-Inkl hides the response header, so there a one-line probe file printed the version and was deleted again right afterwards. At united-domains and CheckDomain the version could not be read from the outside.
| Where | Before | Patched (German time) | Time after the release |
|---|---|---|---|
| STRATO (3 websites) | 8.2.34 | 8.2.35 at 17:51, still old at 17:46 | 1 h 51 min |
| Raidboxes (1 shop) | 8.4.26 | 8.4.27 at the first check at 18:10 | at most 2 h 10 min |
| Own server with Docker | 8.4.26 | 8.4.27 at 18:51, after the rebuild | 2 h 51 min |
| Hostinger (8 systems, LiteSpeed) | 8.3.35 | still 8.3.35 on October 22 at 6:53, 8.3.36 at the re-measurement on October 26 | more than 14 h 53 min |
| All-Inkl, account 1 | not measured | 8.3.36 on October 22 | under one day |
| All-Inkl, account 2 | 8.4.24 | not re-measured | open |
| Unknown host behind Cloudflare | 8.2.29 | 8.2.35 at the re-measurement on October 26 | not measured |
| united-domains, CheckDomain | Version not readable from the outside | ||
Two caveats belong here. We measured our own accounts, not a sample across all of a host's servers. Large hosts often roll updates out server by server, so other customers may have been patched earlier or later. And between October 22 and 26 we did not measure at Hostinger, so we do not know exactly when 8.3.36 arrived.
What we take from it
The range is wide, and you cannot see it
Between the fastest and the slowest host in our measurement lie at least 13 hours, a whole night. From the outside you cannot tell whether a website's server has been patched yet. If you do not check yourself, you do not know.
Your own server is only as fast as its slowest step
One application on our own server runs in Docker, built on the official PHP image. The image tagged 8.4.27 appeared at 17:45, the variant for ordinary Intel and AMD servers not until 18:47. Our rebuild ran at 18:51. To make it pull the new base image at all, rather than taking the old one from the cache, we had to change the build instructions. Since then every build fetches the current image.
Coolify, the platform we use to manage this server, published its update with the patched PHP version just twelve minutes after the release. It still only reached us with the nightly automatic update. Fast vendors help little if the update stays sitting on your system.
Old PHP branches get nothing any more
One system was still on PHP 8.1. For 8.1 and older the PHP project no longer builds releases; there are only minimal fixes in the source code, for those who compile PHP themselves. On shared hosting the only option there is to move to a supported branch. Another system was already five releases behind before the security release, on 8.2.29 instead of 8.2.34. The good news: the security release pulled it along, and at the re-measurement it ran on 8.2.35.
No PHP, no PHP vulnerability
Our main site hafenstudios.com was not affected because it consists of static HTML files. For a WordPress site that is not an option, but it shows why parts that do not need PHP should not run any.
How to check your PHP version in WordPress
- In the dashboard: go to Tools > Site Health > Info tab and expand the Server section. It shows the PHP version WordPress is currently running on.
- Compare it with the table: your branch is patched from the number in the Patched from column.
- Read suffixes correctly: a host's abbreviation can follow the number, such as
8.3.36-nmm1. What counts is the number before it.
| Your PHP branch | Patched from | Supported until |
|---|---|---|
| 8.5 | 8.5.12 | ongoing |
| 8.4 | 8.4.27 | ongoing |
| 8.3 | 8.3.36 | ongoing |
| 8.2 | 8.2.35 | December 31, 2026 |
| 8.1 and older | no release | ended |
One exception: some Linux distributions and hosts build the fix into their own package without changing the version number. If you see an older number and your host says it has patched, that is not a contradiction. In that case its written statement is what counts.
If you look after many sites, from WordPress 6.9 you can also check via the REST API, with an application password and read-only: /wp-json/wp-abilities/v1/abilities/core/get-environment-info/run returns the PHP version, among other things.
If your host has not patched yet
- Ask. One short sentence to support is enough: when is PHP 8.x.y coming with the fix for CVE-2026-109618 and CVE-2026-109619? The answer also shows you how seriously your host takes this.
- Switch branch. Many hosts offer several PHP versions to choose from. If another branch is already patched, you can switch to it after a short test. Make a backup first, then click through the home page, the login and your forms afterwards.
- A firewall as a bridge. Cloudflare has rolled out rules against known attack routes, including on the free plan. But the PHP project states clearly that there is no complete mitigation. A firewall is no substitute for the update.
- On your own servers: update packages, rebuild containers with a fresh base image and then restart all PHP processes. The settings the PHP project suggests for bridging the time until the update are listed in the security advisory.
On October 23 an addendum followed: a third vulnerability, CVE-2026-115560, sits in the upload progress tracking in sessions. It only applies if an application changes the storage format of its PHP sessions at runtime. WordPress itself does not use PHP sessions; at most, plugins that do would come into question. The fix comes with the next regular release, and until then the PHP project recommends session.upload_progress.enabled=0. On shared hosting only the host can set that.
And if you are tidying up anyway: PHP updates are only one half. Why outdated plugins are the bigger ongoing problem is covered in our article on updating WordPress plugins. How outdated some minimum requirements in the plugin directory still are is shown by our analysis: 8,131 plugins still name PHP 5.
Rather have it checked?
With our security check & hardening we look for vulnerabilities in core, theme and plugins, harden the login, check your backups and write you a report sorted by urgency. Fixed price from €490.
Frequently asked questions
Which PHP versions fix php2shell?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, all released on October 21, 2026. Any lower number in the same branch is affected. The PHP project no longer builds releases for PHP 8.1 and older, so there the only options are to move to a supported branch or to use a vendor that backports the fix itself.
How do I find out which PHP version my WordPress site uses?
In the dashboard under Tools > Site Health > Info tab > Server. That shows the PHP version WordPress is currently running on. A suffix such as -nmm1 after the number comes from the host; what counts is the number before it.
Is my WordPress site affected if it shows no security problems?
Yes, if it runs on an unpatched PHP version. The vulnerabilities are in PHP itself and take effect before WordPress or any plugin runs code. A security plugin sees nothing of it. All that matters is the PHP version on the server.
Does a web application firewall help against php2shell?
In part. Cloudflare has rolled out rules against known attack routes, including on the free plan. The PHP project states explicitly, though, that there is no complete mitigation and that only the update is safe. At best, a firewall bridges the time until your host has patched.
My host has not patched yet. What can I do?
Ask support when the patched version is coming. Check in the hosting control panel whether another PHP branch is already offered in a patched version, and switch to it after a test. If your site still runs on PHP 8.1 or older, now is the time to move, because no more releases are coming for those.
