The Critical PHP Security Vulnerability: What Happened and What We Did

On Wednesday 21 October 2026, the PHP project released fixes for two critical security vulnerabilities and asked everyone running PHP to update straight away. The Australian Cyber Security Centre issued a critical alert the same day.

If your website is hosted with us, you don’t need to do anything. Here is what the PHP security vulnerability was, what we did about it, and what it tells us about how websites are built.

What the PHP vulnerability was, in plain English

PHP is the programming language that runs on the web server behind a huge number of websites, including every WordPress website. When someone visits a page or fills in a form, PHP does the work of building the page and handling what they sent.

The two flaws are recorded as CVE-2026-109618 and CVE-2026-109619. Both are rated critical. Both come down to PHP mishandling its own memory in unusual situations: one when a request runs out of memory partway through, the other when leftover data from one visit is not cleared properly before the next one arrives.

What makes them serious is what an attacker could do with them. According to the PHP security advisory, both can allow unauthenticated remote code execution. That means someone with no login at all could, in the right conditions, send a specially crafted request to a website and get the server to run code of their choosing. The PHP team said a working attack had already been demonstrated, and that it could be triggered before any of the website’s own code runs.

One of the main ways in was through how PHP reads incoming form data, the same mechanism that handles contact forms, checkout pages and file uploads.

The PHP project’s own fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and anything older and unpatched is exposed. Our hosting runs on CloudLinux, which released its own patched builds for every PHP version from 5.2 through to 8.5, so websites on older PHP versions on our servers are covered too. When it published its alert, the ACSC said it was not aware of any successful attacks in Australia using these flaws.

What we did about it

We heard about this overnight and acted first thing on Thursday 22 October.

We restricted the affected part of PHP straight away. Because the flaw could be reached through form submissions and file uploads, our server team temporarily blocked both across our hosting while the patches were installed. Websites stayed online the whole time. Contact forms, checkouts and uploads were paused for a few hours, which is a trade we would make again: a form that is down for a morning is a far smaller problem than a server that has been taken over.

We patched as soon as the fix was available. Our server team applied the security update across our hosting and lifted the block that afternoon. Forms and uploads have been working normally since. Moving fast on something like this is exactly what our cyber security services are for.

Everything is operational, and there is nothing you need to do. If your website is hosted with Webics, the fix is already in place. We kept our status page up to date throughout, and it is the place to check if you ever want to know what is happening with our hosting.

One thing worth noting: websites that have already moved to the Webics platform were not affected at all, and their forms kept working the whole time. More on why below.

Why every PHP flaw is a WordPress risk

WordPress is written in PHP. So is every WordPress plugin and every WordPress theme. That makes a flaw in PHP itself a problem for every WordPress website on the internet at the same moment, whoever built it and however well it is looked after.

That is one layer. On top of it sit WordPress itself and every plugin a site uses, each written by a different team and each needing its own updates. A typical business website might run a page builder, a forms plugin, an SEO plugin, a backup plugin and a handful of others. Every one of them is more code running on the server, and more code means more places for something to go wrong.

None of this means WordPress is unsafe. Kept up to date and properly hosted, it is a solid platform, and we have built hundreds of websites on it. But it does mean the work never stops. Updates have to be applied, plugins have to be checked, and when something like this week’s PHP issue lands, someone has to move quickly. That is a big part of what our hosting and care looks after.

Why we are moving clients to the Webics platform

The Webics platform takes a different approach. Instead of building each page on the server every time someone visits, your website is a fast static build: the pages are made ahead of time and served from the cloud as they are. There is no PHP running behind them and no stack of plugins to keep patched.

That removes this whole class of risk. A PHP vulnerability cannot affect a website that does not run PHP, which is exactly why our clients on the Webics platform carried on as normal on Thursday while we were patching everything else.

It is not magic, and we will not pretend it is. Any website still needs good passwords, multi-factor authentication on the accounts behind it and sensible habits from the people who use it. Our cybersecurity checklist covers those. What changes is the size of the target. With far less software exposed to the internet, there is far less to attack, and far less to update.

There are other benefits too. Static pages load quickly, which helps both your visitors and your search rankings, and your contact forms keep working. You can see more about how we build websites on our web design and development page.

Thinking about moving your website off WordPress?

If your website runs on WordPress and you would rather spend less time worrying about the next PHP vulnerability or plugin update, talk to us about upgrading to the Webics platform. We will look at what your current site does, tell you honestly whether moving makes sense, and carry your content across with it.

Get a quote or contact us to start the conversation.