Security and performance

Two critical PHP flaws were patched on 21 October. Updating WordPress doesn’t fix them.

José Debuchy 3 min read

On this page
A WordPress site's layers resting on the server layer, where the PHP fix is applied

On 21 October 2026 the PHP team released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The releases fix two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 on CVSS v4.0. In the PHP team’s words, they “can allow unauthenticated remote code execution”: an attacker could run code on your server without logging in.

WordPress runs on PHP, so every WordPress site sits on top of this. And this is the part most site owners miss: the fix is a PHP update on the server. Updating WordPress core, your theme or your plugins does not fix it.

Diagram of a WordPress site's layers and who updates each one; the PHP layer, updated by the host, is where the October fix applies

What the PHP team said

  • 20 October: advance notice of a critical security release, scheduled for 21 October at 14:00 UTC.
  • 21 October: the four releases above. Each one says: “There are no complete mitigations, updating is the only safe choice.”
  • 23 October: an informational advisory suggesting session.upload_progress.enabled=0 until the next regular bugfix release, to protect against an unlikely attack path. It mentions a third issue, CVE-2026-115560, with a full advisory to follow.

PHP 8.2 reaches end of life on 31 December 2026. After that date it gets no security fixes at all. PHP 8.3 keeps security fixes until the end of 2027, 8.4 until the end of 2028 and 8.5 until the end of 2029 (php.net supported versions, read 27 October 2026).

Chart of PHP 8.2 to 8.5 support periods; 8.2 loses security support on 31 December 2026

Check your site in two minutes

  1. In WordPress, go to Tools > Site Health > Info > Server. The line “PHP version” shows the version your site runs.
  2. Compare it with the fixed versions: 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or newer in the same branch.
  3. If your version is older, or it is PHP 8.1 or below, your site needs your host’s attention now.

What to ask your host or your development team

  • Which PHP version does our server run, and when was it updated?
  • Have you applied the 21 October security release (CVE-2026-109618 and CVE-2026-109619)?
  • Are we still on PHP 8.2 or older? What is the plan before 8.2’s end of life on 31 December?
  • Who is responsible for PHP updates on our server, and how do we hear about the next one?

Some managed hosts patch PHP for you. WordPress.com, for example, states that every site it hosts is already protected against both flaws. If you can’t get a clear answer to these four questions within a day, that is the real finding.

Why this keeps happening

A WordPress site has layers with different owners: WordPress core, the theme, the plugins, PHP, the web server and the hosting account. Updates for each come from a different place. When a site was built by a team that has moved on, or by an agency that answers late, nobody owns the layer under WordPress, and a flaw like this one waits until someone notices.

If nobody owns your server

40Q takes over WordPress sites that other teams built. We start with an audit of the code, hosting, PHP and plugin versions and security, fix what puts the business at risk first, and then run the site with you every month. See how takeover and support works.

Book a platform review

In 30 minutes we tell you which PHP version your site runs and what taking it over would involve.

Book a platform review

Share

Take the next step

Give your team the autonomy they've been waiting for

Most enterprise teams stay stuck because their CMS slows them down. You can change that today with a clear, low-friction first step.