Critical PHP vulnerabilities (CVE-2026-109618 and CVE-2026-109619): what we have done

On 21 October, the PHP team released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, which fix two critical vulnerabilities known as PHP2Shell: CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10. They let someone run code on a server with a simple request to the website, without a username or password, and they affect practically any PHP installation, whatever the application: WordPress, PrestaShop, Laravel or a hand-built site.

You don't need to do anything: every PHP version on our servers, from 5.2 to 8.5, has been fixed since the early hours of 22 October.

On 23 October, PHP warned about a third route, CVE-2026-115560, which doesn't have a fix yet. On our servers it had been closed since the 21st: we explain it further down.

If your website uses PHP 8.2, 8.3, 8.4 or 8.5, you will see the same number PHP released, for example 8.5.12. With an older version you will see the usual one, for example 7.4.33, and that is expected: PHP doesn't release new versions of those branches, and CloudLinux, which maintains the PHP versions we use, includes the fix in them without changing the number. The table further down lists the fixed release of each branch. Here is what we have done.

Before the fix came out

The day before, PHP announced that it would release the fix on the 21st at 16:00 Spanish time, and the details leaked ahead of time. We didn't wait for the patch: we follow security warnings through every channel, not just the official ones, and as soon as the first unofficial reports started circulating:

• We disabled, on every server, the PHP feature through which the confirmed part of the attack got in: tracking the progress of file uploads in the session. We did it in every PHP version we offer, from 5.2 to 8.5, and checked account by account that it had been disabled.
• We added our own rules to the web application firewall on every server, which reject known attempts before they reach PHP. They come on top of the ones CloudLinux has rolled out in Imunify360.

None of these measures changes anything for your website. The only thing that stops working is the progress bar in applications that calculated it with that PHP feature, which is very rare: most calculate it in the browser.

These measures reduce the risk, but they don't replace the update. That is what the PHP team itself says, and it is why we installed it as soon as it was available.

The update

Our servers use the PHP versions maintained by CloudLinux. We installed its fixed versions as they were released, and since the early hours of 22 October the fix has been applied on every server, in every version we offer: from 5.2 to 8.5.

From 8.2 to 8.5, the number is now the one PHP released with the fix: 8.5.12, for example. In older versions, CloudLinux includes the fix without changing the version number, which is why PHP still shows the usual one: 7.4.33, for example.

In 8.2, 8.3, 8.4 and 8.5, CloudLinux first released the fix without changing the number, and that is what we installed on the 21st and 22nd: if you saw 8.5.11 on your website on those days, it was already fixed. It then released the same fixes with PHP's numbers, and we have installed those too: they change the number, not the protection, which was already in place since the 22nd. In CloudLinux's words: "If you have already installed the fixed packages from our earlier updates (for example alt-php85 8.5.11-5), your servers are already protected against CVE-2026-109618 and CVE-2026-109619. This update only brings the version numbers in line with PHP.net". In other words: anyone who already had the earlier packages, such as 8.5.11-5, was protected, and the new ones only bring the number in line with PHP's. It explains this in its notice about these vulnerabilities.

The update didn't need anything from you and didn't interrupt the service.

The 23 October notice: CVE-2026-115560

On 23 October, the PHP team warned about another way to run code on the server, CVE-2026-115560. The versions of the 21st don't fix it: the fix will come with the next PHP release. It is a different route, and what those versions fix, CVE-2026-109618 and CVE-2026-109619, is still fixed.

It can only be exploited in an unusual combination: the application changes, in its own code, the format in which PHP stores the session, and tracking the progress of file uploads in the session is also enabled. Until the fix arrives, PHP recommends disabling that feature, and points out that anyone who already did so after its notice on the 21st doesn't need to do anything else.

That is our case: it is the same feature we disabled on 21 October on every server and in every PHP version, from 5.2 to 8.5, and it is still disabled. The web application firewall rules we added that day also reject requests that try to use it before they reach PHP. You don't need to do anything. When PHP and CloudLinux release the fix, we will install it just like this one.

What if my website uses an older PHP version?

The PHP project only fixes the versions it maintains: 8.2 onwards. For 8.1, 7.x and 5.x it doesn't release new versions. With most hosting providers, a website on PHP 7.4 is left unprotected today.

Not at Hostsuar. CloudLinux maintains security patches for every version we offer, from 5.2 to 8.5, and it has also fixed these two vulnerabilities in the older ones. The fix is already installed in them, just like in the rest: your website is protected without changing version.

Keeping the version you use up to date is our job, so you don't need to change PHP version because of these vulnerabilities. If one day you want to move to a newer one, for performance or because a new plugin asks for it, you can see which versions there are in PHP versions available on all hosting services and change your website's in Change a website's PHP version with checks and rollback: we check that the website still responds with the new version and, if it doesn't, it goes back to the previous one. If your website needs changes to work on a current version, write to us and we'll look into it.

If you run PHP elsewhere

If you manage a server with PHP yourself outside Hostsuar, update it to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your distribution's fixed package, and restart PHP. For CVE-2026-115560, also set session.upload_progress.enabled = 0 in php.ini or in the PHP-FPM configuration before restarting it: setting it with ini_set() from the application doesn't work. If you have any questions about how to do it, write to us.