Two critical PHP flaws. Every WPX server patched in 90 minutes.

On 21 October, PHP shipped fixes for two critical vulnerabilities that allow remote code execution on almost any PHP website. Here is what we did, when we did it, and why WPX customers never had to lift a finger.

The case in short: 

• The threat: 2 critical PHP vulnerabilities – CVE-2026-109618 and CVE-2026-109619 – both rated 9.2 out of 10, and both allow unauthenticated remote code execution.
• Before the fix existed: our admins had hardening rules live on every server, on every PHP version.
• After the fix shipped: We started rolling them out at 17:30. By 19:00, every server was patched.
• Old PHP versions: every site still running PHP older than 7.4 was moved to patched PHP 7.4. No WPX site runs anything older today.

What happened in detail: 

PHP runs most of the web, WordPress included. On 20 October 2026, the PHP project announced an upcoming security release. On 21 October, it shipped fixes for two flaws serious enough that CERT-EU, the EU’s cybersecurity response team, issued a critical advisory the same day.

CVE-2026-109618 sits in how PHP handles running out of memory mid-request, for example during a file upload. Memory that was never properly set up gets cleaned up anyway, and it can contain attacker-controlled data.

CVE-2026-109619 lets leftover state from one crashed request leak into the next request handled by the same PHP worker. The confirmed attack paths run through PHP’s session upload progress feature.

The short version: an attacker with no login could run their own code on the server. CERT-EU reported that proof-of-concept exploits were already circulating.

The execution timeline: 

All times are Sofia time (EEST) on 21 October 2026, unless noted.

From the official fix to every server patched: 90 minutes.

What we did, step by step

1. We heard early: Our admin team picked up the advance notice through security channels as soon as the PHP project flagged it, before the technical details went public. The goal with any vulnerability is simple: have defenses in place before attackers know where to look.
2. We hardened every server before a patch existed.
   Two changes went live across all PHP versions and all sites. First, we switched off PHP’s session upload progress feature, the same mitigation CERT-EU recommends for CVE-2026-109619. Second, we added a Web Application Firewall rule that challenges upload requests with a CAPTCHA. That stops most automated attack scripts cold. 
3. Then we checked our own stack.
   WPX runs on LiteSpeed web servers with LSPHP. Our engineers assessed that the attack paths, as disclosed, did not apply to our published setup. We kept the hardening on anyway. “Probably not affected” is not a security policy.
4. We installed the official patches the moment they landed.
   We started at 17:30. By 19:00, every server running PHP 7.4 or newer was on a patched build. In parallel, a small number of sites were still running PHP versions older than 7.4. We upgraded every one of them to a patched PHP 7.4. Today, no site on WPX runs anything older.
5. We put everything back.
   With the real fix in place, the temporary rules had done their job. Then we removed them so uploads, forms, and everything else returned to exactly how they worked before.

The trade-off we made

For a few hours on 21 October, some uploads on WPX sites asked for a CAPTCHA, and a few upload features behaved differently. That was us. It was deliberate.

A short inconvenience beat leaving a door open while the patch was on its way. Once we installed the official fix, we removed the rules, and everything went back to normal. If you noticed it, now you know why.

What you need to do

If your site is hosted with WPX, then nothing. The patches are installed, the temporary rules are gone, and your site runs exactly as it did before.

If you run sites anywhere else, check your PHP by asking your host which version it is and if it’s patched. 

Why this is our job, not yours

A critical vulnerability is a race. The riskiest window is the one between the details going public and the patch reaching your server. On WPX, we closed that window before it opened, then installed the real fix within hours of its release.

While our admins worked on the servers, our support team answered every chat and ticket in real time. Real people, not a chatbot, as always.

The only thing our customers noticed was the result.

Victor Perez and Daniel Stanica on Facebook, 22 October 2026.

WPX customer, on Live chat, 21 October 2026.

WPX customer on Live chat, 21 October 2026.

WPX customer on Live chat, 21 October 2026.

WPX customer on Live chat, 21 October 2026.

That is what managed WordPress hosting should mean. You run your business. We watch the servers. 

Not on WPX yet? See our plans and let our team move your sites over for you.