Critical PHP vulnerability of October 21, 2026: what we did to protect your websites

On Wednesday, October 21, 2026, the PHP team released a security fix for two critical vulnerabilities affecting virtually every website written in PHP, WordPress included. From this morning, we protected our servers, then applied the fix as soon as it was released. Here is what happened, what we did for our clients' websites, and what you can check on your side if you are hosted elsewhere.

On October 20, php.net announced that a critical update would be released the next day at 14:00 UTC (4 p.m. Paris time) to fix two vulnerabilities rated 9.2 on the CVSS v4.0 scale, which puts them in the "critical" category.

On October 21, PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 were released. They fix CVE-2026-109618 and CVE-2026-109619, both of which allow unauthenticated remote code execution. In plain terms: an attacker could make the server run their own instructions, without any account or password, simply by sending a specially crafted request.

For the curious, here is what they are about in a few words:

• CVE-2026-109618 ("RCE via OOM corruption"): insufficient memory handling can interrupt PHP while internal request data is only partially initialized. End-of-request cleanup may then treat that data as valid.
• CVE-2026-109619 ("RCE via stale global state"): internal state that belongs to one request can survive after its memory has been freed, and a later request handled by the same process may use it.

Every PHP installation serving web requests is affected: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed. An exploit has been demonstrated under mod_php, where an anonymous request triggers the attack before the website's own code even runs. The confirmed path goes through the file upload progress tracking feature (session.upload_progress), enabled by default in PHP and triggered by multipart form submissions, even if the website does not use sessions. In other words, a simple contact form is enough to reach the feature in question.

Important: PHP 8.1 and earlier no longer receive official updates, so they get no fix. PHP 8.2 reaches end of life on December 31, 2026.

The official advisory is available here: php.net

Our clients' websites are hosted on dedicated servers and VPS running Plesk, at OVH. Here are the actions we took, in order.

First of all, we listed every PHP project we maintain, with the PHP version used in production and the way PHP runs for each of them. You can only protect well what you know precisely.

With the fix only expected at 4 p.m., we did not wait. php.net states that disabling session.upload_progress reduces exposure to the confirmed attack path. We therefore disabled it at server level, for every installed PHP version (12 versions on a single server), then reloaded all PHP-FPM processes.

We did not just change the configuration: a small test script queried each website to read the value actually applied. What is written in a file and what PHP really applies can differ, and that is exactly what we wanted to rule out.

php.net is clear on this point: these mitigations reduce exposure but do not make a website safe. Only the update is a complete solution. It was a stopgap measure, not an end in itself.

Since PHP 8.1 and earlier will never get a fix, we made sure no website is served by an end-of-life version anymore. The few websites concerned were either migrated to a maintained version or decommissioned: for example, an old staging environment that was no longer needed was removed. Fewer exposed websites means a smaller attack surface.

When the fixed versions came out, we updated the PHP packages provided by Plesk to 8.2.35, 8.3.36 and 8.4.27. We then checked three things: the versions actually installed, the effective restart of the services, and the version actually served by each website.

Even after the update, we kept session.upload_progress disabled. It is an extra layer of protection, in a defense-in-depth approach.

When we started the update, apt rejected the Plesk PHP repositories with a NO_PUBKEY error. The reason: Plesk now signs its repositories with a new key (ID 5B6AB2160B50DB96, created in August 2026) that was not present on the servers.

Without that fix, the servers would never have seen the update. No visible alert, no update, and websites that remain vulnerable while everyone believes they are up to date. This kind of problem only shows up if you actually check what is going on.

We re-imported the official key from https://autoinstall.plesk.com/plesk.gpg into the keyring referenced by the signed-by directive (/etc/apt/keyrings/plesk.gpg), after checking that it did contain the new key. If you manage a Plesk server, this is something to check right away.

If your website is hosted and maintained by StartingUp, you have nothing to do. It runs on a maintained and patched PHP version, the mitigation recommended by php.net is applied, and we checked, website by website, the version actually served.

If your website is hosted elsewhere, the next section gives you the right reflexes for your situation.

On shared hosting, the host updates PHP. You have no control over the packages, but you can check:

• the PHP version actually served by your website, through your host's interface or a temporary phpinfo file (to be deleted right afterwards);
• that it is a maintained version: 8.2 at the very least, ideally 8.3 or later;
• that this version is actually patched (8.2.35, 8.3.36, 8.4.27 or 8.5.12).

Note: according to php.net, the session.upload_progress.enabled=0 mitigation is not effective through .user.ini or ini_set(). On shared hosting, you therefore cannot reliably apply it yourself; only the update by your host counts.

You are in control, and therefore responsible. In order:

1. Check that the repositories are reachable and properly signed: apt-get update must not return any GPG error.
2. Update the PHP packages to a patched version.
3. Reload PHP-FPM (or restart Apache if you use mod_php) so that every worker uses the new binary.
4. Apply the mitigation in php.ini or the FPM configuration, never through .user.ini or ini_set(), then reload again.
5. Check the value actually served, website by website.

A few generic, safe commands.

Check the repositories and the absence of GPG errors:

Check the installed version for a given PHP version (8.3 here):

Reload PHP-FPM after an update or a configuration change:

To check the value actually applied on the web side, temporarily upload a PHP file containing the following, open it in a browser, then delete it:

If the displayed version is not patched, or if upload_progress is 1, the website is not protected, whatever your configuration files say.

Finally, if you are still on PHP 8.1 or earlier, no update will come: migrating to a maintained version is the only option. And if you are on 8.2, start planning now for its end of life on December 31, 2026.

If you are unsure about your website's PHP version, if your host is not answering, or if you simply want an outside eye to check that everything is in order, get in touch. We can review your situation with you and, if needed, take care of the update or the migration.