PHP is fixing two critical flaws this afternoon. Get ready to update

If your website runs on PHP, and that includes every WordPress, WooCommerce and Magento site, plan to update PHP this afternoon or as soon as your host can. The PHP team releases fixes for two critical flaws at 14:00 UTC today, which is 3pm UK time.

Here's what's known, what isn't, and what to do today.

What happened

On 20 October the PHP security team put a notice on php.net giving advance warning of an "upcoming security release". It fixes two critical flaws, tracked as CVE-2026-109618 and CVE-2026-109619, and both are rated 9.2 out of 10.

The notice says "All PHP users are encouraged to prepare now", and that they may release early if the details get out or attacks start.

That's about all PHP has said so far. Their notice says the full details, the affected versions and the fixed versions "will be published with the release". So until 3pm, nobody can tell you which version number to update to.

How bad is it?

The security firm Sansec has a write-up on the two flaws. It says they let an attacker run their own code on the server, and that they affect web servers running PHP 5.4 or later. PHP hasn't confirmed the version range yet, but that would cover almost any PHP site you're likely to have.

Sansec says it "expects mass attacks within 15 minutes of the release". Once a fix is out, people compare the old and new code to work out what changed, and scripts start trying it on every site they can find. Nobody picks your site by hand.

Does it affect you?

If you're on shared hosting or a managed WordPress platform, your host runs PHP for you. It's their job to update it, and good hosts will be ready for this one. It's still worth checking their status page or blog this afternoon for a mention of it.

If you have your own server or virtual server, it's your job. This shows the PHP version:

php -v

Your website might use a different PHP from the one on the command line, especially if the server has more than one version installed. In cPanel or Plesk, the PHP settings for each site show which version it uses. On a plain Debian or Ubuntu server, this lists what's installed:

dpkg -l | grep php

Look at the first number. PHP's supported versions page lists 8.2, 8.3, 8.4 and 8.5 as the versions it still fixes. If you're on 8.1, 7.x or older, PHP itself isn't supporting your version, so don't expect a fix from it. Some Linux distributions copy fixes into their own builds of older versions, so check with yours. Otherwise the answer is to move to a supported version, and that's a bigger job than an update.

What to do today

1. Find every server and site that runs PHP. Including the old one that nobody touches any more. Scripts don't care how old it is.

2. Be ready to update after 3pm. If you installed PHP from your Linux distribution, the fix arrives when they package it. That may be later today or over the next few days. Check their security pages (for Debian, the security tracker; for Ubuntu, Ubuntu's security pages) and install it the moment it lands. On Debian or Ubuntu that's sudo apt update && sudo apt upgrade.

3. Restart PHP afterwards. An updated package doesn't help while the old version is still running. If you use PHP-FPM, restart it (the service name includes the version, such as php8.2-fpm). If PHP runs inside Apache, restart Apache. Then run php -v again and check the number.

4. Consider Sansec's stopgap settings. Until you can update, Sansec suggests setting session.upload_progress.enabled to 0 and session.use_strict_mode to 1 in your PHP configuration, then reloading. Sansec says this isn't a guarantee, and strict mode doesn't help if your sessions are stored in Redis or a database. Test your site afterwards. Treat this as buying time, not as the fix.

5. If you rent a server with a managed control panel, send your host a short ticket today: "Will you be updating PHP for CVE-2026-109618 and CVE-2026-109619 today?" A good host will have an answer.

If you're on an old version

This is the week where an old PHP version stops being a "we'll get round to it" job. If you're on 7.4 or 8.1 because an old plugin or theme needed it, the risk has just gone up sharply. Moving to 8.3 or 8.4 can break things, so test on a copy of the site first. But it's far less painful than cleaning up after someone else has been running code on your server.

The bigger point

Most weeks, PHP updates arrive with your normal updates and nobody notices. This week, the gap between "the fix is out" and "someone tries it on your site" may be very short. Being ready matters more than usual: knowing which servers run PHP, which version, and who's going to press the button.

If nobody in your business is going to do that this afternoon, that's what a support retainer is for. I keep your servers updated, restart what needs restarting, and tell you about it in plain English.