Why Keeping PHP Up to Date Matters After Two Critical Flaws

On 21 October 2026 the PHP project released fixes for two critical vulnerabilities that can allow an attacker to run code on a web server without logging in. Every organisation with a PHP website has since had to find out which version it runs and whether the host has applied the fix. For anyone responsible for WordPress maintenance and security for B2B organisations, that meant a morning of checking versions and reading host status pages.

The National Cyber Security Centre urged UK organisations to take immediate action and said that organisations using any version of PHP are affected. That includes every WordPress website, because WordPress is built on PHP. This post covers what happened, which versions have a fix, why older versions are left exposed and how to check your own website.

What Happened With the PHP Vulnerabilities

Two critical vulnerabilities in PHP, tracked as CVE-2026-109618 and CVE-2026-109619, were fixed on 21 October 2026 after the PHP project announced the release the day before. Both are rated 9.2 on the CVSS scale and both can allow unauthenticated remote code execution, which means an attacker does not need an account or a password to take control of the server.

The first flaw is a memory corruption problem. When a request uses more memory than PHP allows, PHP aborts it. That can happen while internal request data is only partly set up, so the cleanup that follows may try to free memory that was never initialised. The second flaw lets request state survive after the memory behind it has been freed, so a later request handled by the same worker can pick up stale data before it is reset. CERT-EU reported that technical details were being discussed publicly and that proof of concept code had started to circulate, which raises the likelihood that attackers were already using it.

The PHP project said every PHP installation serving web requests is at risk. It added that the risk is highest where PHP runs as an Apache module because a single unauthenticated request can trigger the attack before any application code runs. That is why a WordPress plugin update or a security plugin could not have closed this one. The flaw sits in PHP itself, so the fix has to come from the PHP version on the server.

Which PHP Versions Received a Fix

The fix is in PHP 8.5.12, PHP 8.4.27, PHP 8.3.36 and PHP 8.2.35. Nothing older receives an official patch. The PHP project states that PHP 8.1 and older no longer receive updates from the project, so a website on one of those branches cannot be fixed by an update alone.

The table below sets out the patched release for each branch alongside the date its security support ends, taken from the PHP supported versions page. Any website on a branch that is not in the table is running a version the PHP project no longer maintains.

PHP 8.2 is patched today but its security support ends in just over two months, so a website on that branch has a short runway before it faces the same question as the older versions. Moving to 8.3 or 8.4 now removes that deadline from the diary.

Why Older PHP Versions Are a Risk

Older PHP versions are a risk because they stop receiving security fixes from the PHP project, so any flaw found afterwards stays open for good, as the guide to running an end of life PHP version explains. PHP 8.1 reached end of life on 31 December 2025, PHP 8.0 on 26 November 2023 and PHP 7.4 on 28 November 2022, according to the PHP end of life list.

Some distributions and long term support vendors backport fixes to older versions, so a host running an old branch may still be protected. The catch is that you have to ask the host to confirm it, because the version number on the server may not change when a fix is backported. Without that confirmation an old version should be treated as exposed.

WordPress itself has been moving the same way. The WordPress project now recommends PHP 8.3 or greater and notes that PHP 7.4 and above still work but have reached end of life and may expose a website to security vulnerabilities.

A website that sits on an unsupported version also tends to sit on old plugins and themes, because the two are usually neglected together. That combination is what turns a patching headline into a real incident.

What Hosting Companies Did

Hosting companies responded within hours of the announcement. The response differed from one provider to the next. Some applied temporary rules at the server to limit how PHP accepts file uploads and reduced the number of PHP workers while they rolled out patched builds, then removed those rules once the fixed versions were running.

Temporary rules of that kind can have side effects. Contact forms, basket uploads and any feature that relies on a file or form submission may have failed for a short period while the rules were in place, which is a reason to test your own forms and checkouts and to tell your team what happened if a customer mentions an error.

A host can patch the PHP versions it supports, but it cannot move a website off a version it no longer maintains. That job sits with whoever looks after the website. It is the reason the arrangement between a website owner and a host matters. Where a website is on managed WordPress hosting with a team that watches the PHP version, the host patch and the upgrade work happen as one job.

Why I Feel Smug Today

I will admit to feeling very smug today. Every live website we maintain for clients is on PHP 8.3 or later, which is the range that received an official fix, so the patches our hosting providers rolled out apply to all of them. We did not have a queue of clients to move onto a newer version in a hurry.

That means we have not spent the last day chasing clients for permission to upgrade, booking emergency development time or explaining why a website needs to go offline. Moving a website to a newer version of PHP is part of the maintenance we already do, because PHP version upgrades sit inside our WordPress support retainer. It happens on a normal timetable rather than in a panic. We have always been proactive about it, so this week is the first time that habit has been visible to anyone outside the team.

The smugness has a limit, because keeping websites current is dull work that nobody notices when it goes well. A vulnerability announcement is the one day it shows. The most useful message we sent our clients was that no action was needed on their side. That is the outcome the maintenance exists to produce.

How a PHP Upgrade Should Be Done

A PHP upgrade should be tested on a copy of the website before it reaches the live version, because plugins and themes that rely on features removed in newer versions can break the moment the version changes. The order of work matters more than the speed of it, and the PHP upgrade checklist sets out what to test.

Online shops need the most care because a failed checkout loses sales immediately. Our post on what to do when a WooCommerce update breaks your store covers the recovery side. The same testing steps above are what prevent most of those incidents.

How to Check Which PHP Version Your Website Runs

You can check your PHP version from the WordPress dashboard by opening Tools, then Site Health, then the Info tab and expanding the Server section. The WordPress guidance on updating PHP sets out the same route and explains why the version matters.

A website is in the patched range when it runs 8.2.35, 8.3.36, 8.4.27, 8.5.12 or any later release of those branches. Because some hosts backport fixes without changing the number, ask your host to confirm in writing that the fix is applied if the version looks low. Treat anything on 8.1 or older as unpatched until the host says otherwise.

The NCSC also advises that updating should be a routine control rather than something done on demand, a point made in its vulnerability management guidance. A regular schedule for PHP, WordPress core and plugins is what makes a week like this one uneventful.

Keeping PHP Current Through the Year

Keeping PHP current means checking the supported branches twice a year and moving before a branch reaches the end of its security support, not after it. The dates are published well in advance, so an upgrade can be planned and tested instead of rushed. The overview of PHP versions and which one a website should run shows where each branch sits.

For most WordPress websites the sensible target is PHP 8.3 or 8.4, which gives security support into 2027 or 2028 and matches what WordPress recommends. Websites still on 8.2 should be scheduled for a move before the end of the year. Websites on 8.1 or older should move now.

Anyone who needs help with this can get in touch. If you are weighing up who should look after it, our guide to choosing a WordPress support and maintenance provider sets out what to ask.