PHP2Shell: How We Patched Our Servers on 21 October

Field Notes from 21 October 2026. Two PHP vulnerabilities, six servers, one long evening. Every time below is Eastern (EDT), with UTC in brackets.

On Wednesday 21 October the PHP project published fixes for two critical vulnerabilities, and by that evening websites around the world were going offline while their administrators responded. If you host with us, here is the short version: every website we host runs a fixed version of PHP, the control panel on our servers runs a fixed version too, and you don’t need to do anything. The rest of this post is how the day went, for anyone who wants to see the working.

Two bugs in the engine room

PHP is the language WordPress is written in, and it sits underneath a large share of the websites on the internet. The PHP security team’s advisory describes two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell.

Either one can let someone who is not logged in run their own code on a server that handles web requests with an unpatched PHP. The advisory names every common way of serving PHP as at risk, including LiteSpeed, the web server our sites run on. The fix is a new release in each supported line: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older get no new release from the PHP project.

A morning of warnings from around the world

The unusual part of this story was the reaction. Before the fixed releases were even out, Japan’s Prime Minister, Sanae Takaichi, posted on X asking everyone to act that night: “皆様に、今夜に対応して頂きたい大至急のお願いです。” (roughly, “An urgent request to everyone: please take action tonight.”) The post went up at 8:55 a.m. EDT (12:55 UTC).

According to Jiji Press, she urged people to be ready to apply the patch as soon as it was released, and said that temporarily suspending website functions is an effective way to reduce the risk where patching promptly is difficult. Sakura Internet, a large Japanese cloud provider, announced it would suspend some functions of its cloud service.

In the United States, the FBI’s Cyber Division posted its own warning at 10:59 a.m. EDT (14:59 UTC), and CISA published an alert, Critical Vulnerabilities in PHP Require Immediate Patching. CISA’s advice was direct: update to a fixed release immediately, and if you cannot update yet, or you still run PHP 8.1 or older, take PHP-based systems offline until they can be patched.

The Record counted warnings from the EU, the US, Germany, Japan, Australia, the UK and the Netherlands, reported that several governments took some of their websites offline before the patch was even released, and that hundreds of websites were down on Wednesday while their administrators responded.

That is the backdrop our clients were reading about. A government agency or a finance team that sees the FBI and a head of government telling people to patch tonight will reasonably ask its web host one question: are we covered? We wanted that answer to be yes, with a timeline behind it.

First question: which PHP do our sites actually run?

A fix only helps if it reaches the copy of PHP your site really uses, so we started with an inventory. Between 11:50 and 11:58 a.m. EDT (15:50 to 15:58 UTC) we read every one of our six servers. What we found:

• Every PHP website we host runs PHP 8.3, and every one of them gets it from the PHP packages that Plesk, our hosting control panel, builds and maintains.
• No site runs on a copy of PHP from anywhere else, so one update path covers all of them.
• Plesk’s fixed PHP 8.3.36 build was already in its package repository when we looked.
• The control panel itself runs on its own, separate copy of PHP (8.4), and Plesk had not yet released a fix for that one.

We could have left the update to Plesk’s regular overnight cycle. Given the advice coming from CISA and others, we decided to install it ourselves that evening. At 4:53 p.m. EDT (20:53 UTC) we committed to installing PHP 8.3.36 across all six servers that evening, one server first as a canary, then the rest.

A signature that didn’t match

The first install attempt, at 5:06 p.m. EDT (21:06 UTC), stopped before it changed anything. The package manager refused the new packages because their signature didn’t match any key it trusted.

That refusal is the system doing its job: it is exactly what you want to see if someone tampered with a package. The cause here was harmless. Plesk had started signing its packages with a new key, dated 18 August 2026, and none of our servers had it yet. We downloaded the key from Plesk’s own server, checked its size, checksum and fingerprint, and only then added it to each server, at 5:17 p.m. EDT (21:17 UTC) on the first one. The install went through on the next attempt.

Six servers in twenty-four minutes

We installed PHP 8.3.36 on all six servers between 5:18 and 5:42 p.m. EDT (21:18 to 21:42 UTC). Before each install we saved an exact copy of the packages being replaced, so any server could be rolled back to its previous PHP. After each one we checked that:

• every PHP package on the server was the new build, and PHP reported version 8.3.36;
• the same PHP extensions were loaded as before the update;
• sample websites on that server answered normally, read straight from the server and bypassing the cache;
• no new PHP fatal errors had appeared in the site logs since the install.

There was one more thing to check. Updating PHP on disk does not change the PHP that is already running: a worker process started before the update keeps the old version in memory until it exits. So after each install we restarted the web server gracefully and then looked for any PHP process still running old code. A few stragglers aged out on their own within minutes, and one long-stuck command-line process on one server was stopped by hand. By 5:50 p.m. EDT (21:50 UTC), every PHP process serving a site was running the new version.

The control panel’s turn

The websites were covered. The control panel’s own copy of PHP was still waiting on Plesk. Later that evening Plesk released Plesk Obsidian 18.0.81 Update 4. Its change log entry for 21 October reads: “Updated plesk-engine and sw-engine PHP to version 8.4.27”, which is the fixed release in the 8.4 line.

We installed it one server at a time, starting at 7:06 p.m. EDT (23:06 UTC). On most servers we waited for that night’s backup to finish first, so the update and the backup did not compete. Before each install we saved copies of the server’s mail and web server configuration, and after each install we compared them, checked the panel’s PHP reported 8.4.27, and confirmed that sites answered normally and the mail services were up with empty queues. The last server finished at 8:33 p.m. EDT (00:33 UTC, 22 October), and every server came through with the panel on PHP 8.4.27 and its sites and mail answering normally.

At 9:01 p.m. EDT (01:01 UTC) we published our announcement, the short version of this post that you can forward to anyone who asks.

What you need to do

For any website hosted with us: nothing. The fix is on the server, and your site picked it up without any change on your side.

If your organisation also runs PHP somewhere else, on another host, an internal server or a vendor’s system, three quick questions will tell you where you stand:

1. Which PHP version is it running? Compare it against the fixed releases on php.net: 8.5.12, 8.4.27, 8.3.36 or 8.2.35.
2. Is it PHP 8.1 or older? The PHP project no longer releases updates for those versions. Plan an upgrade to a supported version. The PHP security team has published minimal source backports for 7.4, 8.0 and 8.1 for anyone who builds PHP themselves, and your vendor may offer a backported package.
3. Who installs updates on it, and how fast? If the answer is “nobody in particular” or “next month”, that is the gap that CISA’s advice was aimed at.

Questions about your site? Open a ticket in the client area at my.webops.host, or write to support@webops.host.