[ Article ]

Critical PHP vulnerability: what it means for your WordPress site

← All posts
php-macbook

Summary

Two critical PHP flaws can let attackers run code on your web server. Here's what it means for WordPress sites, what to do now, and why maintenance and staging matter.

On 21 October 2026, the PHP project released security updates for two critical vulnerabilities, and the UK's National Cyber Security Centre (NCSC) published an alert about the issue. The short version: if your website runs on PHP, it needs updating. And if your site runs on WordPress, it runs on PHP.

What's the issue?

The two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, are both rated 9.2 on the CVSS v4.0 scale. According to the NCSC, they may allow attackers to run commands on any web server running PHP, without logging in. In technical terms:

  • CVE-2026-109618: an attacker can trigger an out-of-memory condition that corrupts memory. Under certain conditions, this can be used for remote code execution.
  • CVE-2026-109619: internal state from one request can survive after its memory has been freed, and a later request handled by the same worker can use that stale state.

You don't need to understand the details. What matters is that "remote code execution" is the worst category of vulnerability there is. Someone who can run code on your server can change your site, steal data or use the server to attack others.

Which versions are affected?

The NCSC says all versions of PHP are affected. The fixed versions are:

  • PHP 8.5.12
  • PHP 8.4.27
  • PHP 8.3.36
  • PHP 8.2.35

No fix has been released for PHP 8.1 or older. Those versions are no longer supported, so the only way to secure them is to upgrade to a supported release. PHP 8.2 itself reaches end of life on 31 December 2026, so if you're upgrading anyway, aim for a newer version.

The PHP project has published some temporary mitigations, but it's clear that they reduce exposure without making a server safe. In its own words: updating is the only safe choice.

What does this mean for WordPress?

WordPress is written in PHP, so every WordPress site runs on a server with PHP installed. The important thing to understand is that this is not a WordPress bug, and updating WordPress won't fix it. The fix has to happen on the server, by updating PHP itself.

Who does that depends on how your site is hosted:

  • Managed or shared hosting: your host usually updates PHP for you. Check that they have, and check which PHP version your site runs on. You can see it under Tools → Site Health → Info → Server in the WordPress admin.
  • Your own server or VPS: you (or whoever runs it for you) are responsible for updating PHP.
  • Still on PHP 8.1 or older: you need a bigger upgrade. This is also where things can break, because older themes and plugins aren't always compatible with newer PHP versions.

That last point is a problem we see often. A site gets built, launched and then left alone for a few years. The PHP version gets older, the plugins stop getting updates, and when a critical issue like this one shows up, a simple patch turns into a bigger project.

What to do now

Based on the NCSC's advice, adapted for a typical WordPress site:

  1. Find out which PHP version every site you own is running on.
  2. Update to a fixed version, or ask your host to confirm they've done it.
  3. If you're on an unsupported version, plan the upgrade now. Don't wait for the next issue.
  4. If you can't update right away, the NCSC recommends considering taking the system offline and checking it for signs of compromise.

Test on a staging site first

A staging site is a private copy of your live site, running on the same setup, where you can test changes before they reach your visitors. For a PHP upgrade, it's the difference between finding a broken contact form yourself and hearing about it from a customer.

Our usual routine looks like this:

  • Take a full backup of the live site.
  • Copy it to staging and switch staging to the new PHP version.
  • Click through the important parts: forms, checkout, login, search and anything custom.
  • Check the error log for warnings from themes and plugins.
  • Fix what breaks, then roll the change out to the live site.

For a patch release like 8.4.26 to 8.4.27, the risk is small, and with a critical security issue you shouldn't wait days to test. For a jump between versions, like 8.1 to 8.4, staging is where you'll catch the problems.

Why maintenance matters

A website isn't finished when it launches. It runs on software that keeps changing: PHP, WordPress, themes, plugins and the server underneath. Issues like this one are a reminder that keeping all of it up to date isn't optional.

A site that's maintained regularly is easy to patch when something critical comes up: it's already on a supported version, the plugins are current, and a staging setup is ready. A site that's been left alone for years needs an upgrade project first, while the vulnerability is public and attackers know about it.

Not sure which PHP version your site runs on, or whether it's been updated? Get in touch and we'll take a look.