Critical PHP Security Update: What It Means for WordPress, Moodle and Other PHP-Powered Sites

On 21 October 2026, the PHP project released an emergency security update to fix two serious flaws. If your website runs on WordPress, WooCommerce, Magento, Moodle, or almost any other common web platform, this affects the software your site sits on.

You have probably seen this described as a WordPress problem, or a WHMCS problem, or a problem with whatever platform you happen to use. It is none of those. It is a problem in PHP itself, which is a level below all of them.

What PHP actually is, and why you've probably never thought about it

PHP is a programming language that runs on web servers. It is not something you install or see. It is the layer that takes a request from a visitor's browser, builds the page, and sends it back.

The reason this matters to so many people at once is that an enormous amount of the web is built on it. Platforms you may well be running right now:

• WordPress — which powers something like 40% of all websites
• WooCommerce — the WordPress shop plugin
• Magento — enterprise e-commerce
• Moodle — the learning platform used by schools, colleges and training providers
• Laravel — the framework behind a lot of custom business applications
• Billing and client-management tools, including WHMCS

None of these did anything wrong. They are all affected for the same reason: they are written in PHP, so they run on top of the thing that has the flaw. Think of it as a fault in the foundations rather than in any one of the buildings standing on them.

Palo Alto Networks' Unit 42 counted over 22 million servers on the public internet that appear to be affected. It is that broad.

What went wrong, in plain terms

There are two flaws, tracked as CVE-2026-109618 and CVE-2026-109619. Both carry a severity rating of 9.2 out of 10.

Without going into the internals: in certain situations PHP gets interrupted part-way through handling a request and doesn't clean up after itself properly. Leftovers from one visitor's request can be left sitting in memory and picked up during the next one. A skilled attacker can use that to get the server to run instructions of their own choosing.

The important detail for a site owner is when it happens. The flaw can be triggered before any of your website's own code has run. Not after a login. Not through a vulnerable plugin. Before WordPress, or Magento, or anything else, has even started.

Two things that get missed when people do patch

We manage servers for a living, so these are the two failures we expect to see most over the next week.

1. Having more than one version of PHP installed

If your site is on a cPanel or Plesk server — which most shared and reseller hosting is — the server almost certainly has several versions of PHP installed side by side. Someone updates the one their main site uses, sees a new version number, and reasonably concludes they are done. The other versions are still sitting there, still reachable, still unpatched. Every installed version needs attention, not just the one you use.

2. Installing the update isn't the same as it taking effect

PHP runs as a set of long-lived background processes. Updating the files on disk doesn't change the processes already running — they carry on with the old code until they are restarted. One of these two flaws is specifically about data surviving between requests inside those processes, so this is not a technicality. The services have to be restarted, and that step is easy to skip.

If you're on an older version of PHP

PHP 8.1 and anything older no longer receives updates from the PHP project. If your site is on one of those, there is no official fix coming.

Some hosting providers and Linux vendors produce their own backported patches for older versions, so it is worth asking yours directly. But if the answer is no, the only real path forward is moving to a supported version of PHP — which is a project rather than an afternoon, and one that needs testing, because older sites and plugins don't always cope with the jump.

If you have been putting that upgrade off, this is the week it stopped being optional.

Is this being actively used against sites?

Worth being precise, because there is some overstatement going around.

Working exploit code exists. PHP's own advisory describes a demonstrated attack. Unit 42 says it has seen proof-of-concept exploits. At the time of writing, we have not seen a credible, confirmed report of this being used against real sites at scale.

That gap tends to close in days rather than weeks. Treat it as urgent, not as something that has already happened to you.

If you manage your own site, or someone else does

Ask whoever runs your server these questions. They are short, and the answers tell you nearly everything:

1. Which version of PHP is my site running now?
2. Has it been updated to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 — or a patched version from our Linux vendor?
3. Are there other versions of PHP installed on this server, and have those been updated too?
4. Have the PHP services been restarted since the update?

A good host will answer all four without hesitating. Many of the larger ones will have patched before you asked. If you get vague answers, or no answer, that is useful information too.

If you would rather not have this conversation every time something like this comes up, that is what we do. We take on server management, PHP updates, and the security patching that goes with it, so the next critical advisory is already handled by the time you read about it. Get in touch and we'll talk about what you're running.

Common questions

Do I need to update WordPress, or my plugins?

Not for this. You should keep them updated anyway, but this particular flaw isn't fixed by anything inside WordPress.

My site is on managed WordPress hosting. Am I covered?

Probably, and sooner than most — the large managed hosts patch centrally and quickly. Ask them anyway, and ask question 4 above.

Can I check my PHP version myself?

In WordPress, go to Tools → Site Health → Info, and look under Server. That tells you the version your site uses. It won't tell you whether the server has other versions installed, or whether the services have been restarted.

My site is static, or built in something other than PHP

Then this doesn't affect your site. Our own site, for example, isn't PHP and isn't affected. But if it shares a server with PHP sites, the server still needs patching.

Nothing looks wrong with my site. Does that mean I'm fine?

No. There is nothing visible to see either way. A site that hasn't been patched looks exactly like one that has.

If you need a hand

If you are looking at this and aren't sure where to start, or you have found out you're on an unsupported version of PHP and need a plan, get in touch. Existing clients, a support ticket in the client portal is the fastest route.

Sources: PHP security advisory, 21 October 2026 · Unit 42 analysis