Last issue was about who can still log in to your website. This one is about something that needs no login at all and it needs your attention this week.

On 21 October the PHP project released fixes for two critical vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 out of 10. Both allow an attacker to run their own code on a web server without logging in. Security researchers have nicknamed the pair PHP2Shell.

WordPress is written in PHP, so this sits underneath your site. It is not a WordPress flaw and it is not a plugin flaw. That means updating WordPress, your theme and your plugins does not fix it. The WordPress project has said no WordPress update is needed. The fix has to happen on the server.

What is actually at risk

Any site served by PHP on a version older than the fixed ones is exposed in principle. The fixed versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Sites on PHP 8.1 or older no longer get routine updates, so they need a fix from the host or a move to a newer version.

Hosts that run PHP as an Apache module are considered the highest risk and the working attacks published so far target that setup. Public proof-of-concept code exists and attempts against live servers have been reported. At the time of writing, one major security vendor says it has not yet confirmed successful attacks in the wild, but it expects them. Treat it as urgent without treating it as a panic.

Step one: find out where each site stands

Log in to WordPress and go to Tools, then Site Health, then the Info tab. Open the Server section and read the PHP version. If it is one of the fixed versions or newer, you are covered. If it is older, find out whether your host has patched it another way.

That second part matters. Many hosts apply the fix to the server package without changing the version number you can see. So an older number does not automatically mean unpatched. Check your host's status page or ask their support and ask a precise question: has the fix for CVE-2026-109618 and CVE-2026-109619 been applied to the PHP my site runs on?

Step two: act by hosting type

On managed WordPress hosting, the host patches centrally. Your job is to confirm it has happened and keep a note of when. On ordinary shared hosting the host also patches, but rollouts take days, so check back rather than assuming. On a VPS or any server you manage yourself, you install the updated PHP packages and then restart PHP so every running process picks up the fixed version. Updating without restarting leaves the old code running.

If your site is on PHP 8.1 or older and the host cannot confirm a fix, plan the upgrade now. Test it on a staging copy first, as Issue 32 describes, then move the live site.

Step three: reduce exposure while you wait

If you manage the server and cannot patch today, PHP has published temporary measures. They reduce the risk but do not remove it. They include turning off session upload progress, keeping the maximum upload size low and on PHP 8.5, switching off fatal error backtraces. These must be set at server level, because settings made inside the site are applied too late. A firewall rule from a service such as Cloudflare adds another layer, but treat it as a layer and not as the fix.

How I handled it for my clients

On the morning of 22 October I wrote to around fifteen clients. Each email said the same things in plain English: what had been announced, that the fix is a change to the PHP version on the server, what I would do that day and that it was covered by their retainer, so there was no extra cost and nothing for them to do.

For each site I took a full backup first and then moved it to PHP 8.5.12, the latest patched release. I tested the pages that matter, including the contact forms. Where a plugin was not ready for PHP 8.5, the fallback was the patched 8.4.27, so the site was protected either way. I also checked the server logs from 17 October onwards for anything unusual. By mid-afternoon every site was done, and each client got a short message confirming it.

The featured read this week is the PHP security announcement of 21 October 2026. It lists the fixed versions for each branch and links to the official advisories, so it is the safest place to confirm numbers before you act.

If you want a quick view of how well looked after the rest of your site is, the Maintenance Risk Check is a good next step. When you would rather someone checked the version, chased the host, tested the upgrade on a staging copy and handled the whole thing, that is part of what a fixed-price proposal can cover.

Each issue is written to stay useful after send day. This one lives in the archive, filed by topic, so you can come back to it the next time a server-level flaw is announced.

How we can work together

Reply with your PHP version and your host's name and I will tell you whether you are covered and what to do next.