The Critical PHP Security Release: Check Your Version

On 21 October 2026, WordPress.org published a short post titled Critical PHP Security Release. It asks every site owner to “immediately update their installations of PHP”. This is unusual. WordPress does not normally announce problems in the language it runs on, and the post says plainly that no WordPress update is required or planned, because the flaws affect any server running PHP. A WordPress update will not fix this. The fix has to happen on the server.

What PHP actually fixed

The PHP project’s own announcement lists four releases on the same day, one for each supported branch: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. All four fix the same two vulnerabilities:

• CVE-2026-109618: remote code execution caused by memory corruption when PHP runs out of memory part-way through setting up a request.
• CVE-2026-109619: remote code execution caused by internal state from one request surviving into the next request on the same worker process.

PHP describes both as allowing remote code execution without logging in, and rates the risk highest for servers using mod_php. It also says there are no complete workarounds, so updating is the only safe option. “Remote code execution without logging in” is the most serious category there is: in the worst case, an attacker can run their own commands on the server.

Find your PHP version in two minutes

WordPress.org gives the quickest way to check, and it works on any WordPress site:

1. Log in and go to Tools → Site Health.
2. Open the Info tab.
3. Expand the Server section.
4. Read the line labelled PHP version.

Then compare the number with the four fixed releases. If your branch is 8.2, you need 8.2.35 or later. On 8.3 you need 8.3.36 or later, on 8.4 you need 8.4.27, and on 8.5 you need 8.5.12. If the number is lower than these on the same branch, the server is not patched yet.

If your version starts with 8.1, 8.0 or 7.x, the picture is worse. The PHP project no longer updates those branches at all. The WordPress.org post says PHP versions before 8.2 no longer receive security updates. PHP’s security team did publish source backports for 7.4, 8.0 and 8.1, and some Linux distributions and paid support vendors ship their own fixes, but on ordinary shared hosting you cannot rely on that. A site on PHP 8.1 or older should move to a supported branch.

What to ask your host

On shared or managed hosting, you usually cannot install PHP yourself. The host does it. The WordPress.org post notes that many hosts may already be updating PHP or adding firewall rules to reduce the risk. You still need to confirm it for your own account. A short support message is enough:

• “Has the PHP version on my account been updated for CVE-2026-109618 and CVE-2026-109619?”
• “Which exact PHP version is my site running now?”
• “Can I switch my site to PHP 8.3 or 8.4, and is there a staging copy I can test on first?”

Many hosting control panels also have a PHP version selector, so you may be able to switch the branch yourself. Changing the branch, for example from 8.1 to 8.3, is a bigger step than a patch update within the same branch. Old plugins and themes sometimes break on a newer PHP version, so test first if you can.

The WordPress.org post goes one step further for people who run their own servers. If you run a PHP version before 8.2 and cannot upgrade straight away, it points to UK National Cyber Security Centre guidance that says to consider taking the server offline until you can fix it. That is a strong statement, and it shows how seriously the security teams are treating this.

Before you switch PHP versions

A PHP branch change is safe for most modern WordPress sites, but a little preparation avoids a broken site:

1. Take a full backup of files and the database, and make sure you know how to restore it.
2. Update WordPress, plugins and themes first. Current versions are far more likely to support newer PHP. WordPress keeps a table of which PHP versions each WordPress version supports.
3. Remove plugins you don’t use. Inactive plugins can still contain old code, and they are the most common cause of errors after a PHP change.
4. Switch, then click through the site. Check the home page, a post, a contact form, the checkout if you run a shop, and the admin area.
5. Keep the old version one click away in the control panel, in case something breaks and you need time to fix it.

If you are on WooCommerce, note that the plugin is also raising its own minimum PHP version, which the earlier post on WooCommerce dropping PHP 7.4 covers. Both changes point the same way: older PHP is running out of road.

The end-of-life date to put in your calendar

The PHP project’s announcement also gives a date that matters for planning: PHP 8.2 reaches end of life on 31 December 2026, and gets no security fixes after that. So even a site that is fully patched on 8.2.35 today has less than two months before it is back in the same position as an 8.1 site. If you are going to ask your host to switch branches anyway, ask for 8.3 or newer now and do the work once. The PHP supported versions page shows the current dates for every branch.

This was one of two security notices in October. The other was a WordPress release, covered in the post on what WordPress 7.1.4 fixes. A site needs both: the WordPress update fixes WordPress, and the PHP update fixes the server underneath it.