A critical PHP flaw affects nearly every website: the update your hosting provider has to run, not you

On 6 October, WordPress released a security update covering seven separate flaws, including a cross-site scripting vulnerability and a SQL injection issue. Two weeks later, on 21 October, a very different kind of announcement followed. PHP itself, the programming language that runs WordPress and countless other business websites, received a critical update for two flaws rated at the highest possible risk score. For anyone who manages a website, or has one managed for them, that second announcement is the one that matters most, and the easiest one to miss.

Both updates carried the same message: update immediately. But where the WordPress update runs through the familiar Dashboard, Updates screen, the PHP update sits a layer deeper. That difference decides who actually has to apply it, and why you often cannot do so yourself, even if you wanted to.

What exactly happened in October

WordPress 7.1.3 fixed seven security issues on 6 October: among them a cross-site scripting flaw on the comments screen, a denial-of-service bug in the function that processes URLs, and an issue that let a user with a limited role make posts sticky without having permission to do so. None of these is dramatic on its own, but together they show that a CMS powering a large share of the web stays under constant scrutiny, from security researchers and attackers alike.

On 21 October, an advisory of a different order followed. PHP disclosed two critical flaws rated 9.2 on a scale up to 10. Both could in theory lead to remote code execution on a server, the most severe category a vulnerability can fall into. Fixed versions were out within a day: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Why this is a hosting question, not a content question

You install a WordPress update, or have it installed, through the CMS itself. A PHP update sits at a different level: PHP runs on the server, underneath your website, and is managed by whoever manages that server. If you do not have access to the server configuration yourself, a common situation with shared or managed hosting, you cannot apply this update on your own. The risk, then, is not what you forget, but what your hosting provider does or does not do quickly enough.

That makes the choice of hosting provider more relevant than many business owners realise. A provider that rolls out server updates automatically and fast often closes a flaw like this within days. One that works manually, or only reacts once a customer reports something, can leave a critical flaw open for weeks without anyone noticing.

What a risk score of 9.2 means in practice

The official PHP advisory rates the risk highest for servers running mod_php, a common way of running PHP inside the web server. Temporary mitigations, such as disabling a specific configuration setting, reduce the risk somewhat, but the only complete fix is updating to one of the patched versions. For an attacker exploiting a flaw like this, the target is rarely the one website you personally manage. Automated scans constantly search for servers still running the old version, regardless of who owns them.

That also explains why the PHP team moved so fast: patched versions were ready within a day of the first warning, and an upcoming major PHP release picked up the same fix in an early test build. Older, unsupported PHP versions, such as the 8.1 line and earlier, get no official patch at all. If your website still runs on one of those, upgrading to a maintained version is no longer optional if you want to stay secure.

The question worth asking your hosting provider now

You do not need any PHP knowledge to act on this. One direct question to your hosting provider or developer is enough: which PHP version is my website currently running, and has the 21 October update been applied yet? A clear, fast answer is a good sign. A vague answer, or a note that updates only happen at the next scheduled maintenance window, is a signal to have a broader conversation about your hosting arrangement.

Also ask how often this kind of update generally gets applied: automatically with every release, within a fixed window after a critical advisory, or only after an incident. For a website with a contact form, a webshop, or a customer portal, a structural patching process at server level is not excessive caution. It is the foundation the rest of your security rests on.

Maintenance you never see is still maintenance

Most business owners only start thinking about website maintenance once something visibly breaks: a slow page, an error message, a hacked contact form. October's PHP update happened at a level you never see, which is exactly why the risk is so easy to underestimate. Want to know which PHP version your website is currently running, or looking for a hosting partner that rolls out critical updates within days instead of months? Zarioh is happy to think through hosting where this maintenance is handled structurally, not only after an incident.