What changed in October 2026
In late October 2026 the PHP project released security updates for every supported version: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix flaws in the core of PHP that the project’s own advisory treated as critical, because in the wrong conditions an attacker could run their own code on your server without logging in. There is no single setting that fully switches the problem off, so the fix is to update. If your website, billing portal or WordPress site runs on PHP, this affects you.
Check which PHP version your server really runs
Ask your developer or hosting provider for the exact PHP version, or look under PHP settings in your hosting control panel. Be careful with Linux servers: Ubuntu, Debian, CloudLinux and cPanel often add security fixes to a package without changing the familiar version number, so an older-looking number can still be patched. The reliable check is the package changelog, or your provider confirming in writing that the October 2026 fixes are included.
Why PHP 7.4, 8.0 and 8.1 are the bigger risk
These versions no longer receive security fixes from the PHP project. PHP 8.1 stopped on 31 December 2025, and 7.4 well before that. Many older business websites still run on them because an old plugin, theme or piece of custom code breaks on newer PHP. A patch is not available for them, so the real fix is upgrading the code. PHP 8.2 also stops receiving security fixes on 31 December 2026, so plan that move now rather than in a hurry in January.
How we patch a PHP server without breaking the website
We have secured more than 25 PHP servers, and the routine is the same each time. First we list what runs on the server: the PHP version and extensions, WordPress or Laravel versions, scheduled jobs and any custom code. Then we take a full backup, apply the update to a copy of the site and test the pages that bring in business, such as checkout, enquiry forms and invoice downloads. Only then do we update the live server, at a quiet hour, with a tested way back if anything misbehaves.
Patching is only half the job: harden the server too
An up-to-date PHP still needs sensible settings around it. We switch off error messages that reveal file paths, stop the server announcing its PHP version, run each website under its own user so one hacked site cannot read another, tighten file permissions, block access to backup and configuration files, and limit repeated login attempts. None of this replaces patching, but it makes the next flaw much harder to exploit.
Update it yourself, rely on your host or hand it over?
On good shared hosting, the provider usually patches PHP for you; check that they did, and keep your WordPress plugins updated yourself. On your own VPS or cloud server, nobody patches anything unless someone is given that job. A small team can manage it in-house with a monthly routine. When nobody has the time or confidence to test after updates, handing it to a specialist makes sense. Fully automatic updates sound tempting, but on a server with old code they can take a site down at 2 a.m.
What to do this week
Write down every website and server your business depends on, with its PHP version and the name of the person responsible for updating it. Anything below the October 2026 versions needs updating now, and anything on PHP 8.1 or older needs an upgrade plan. The server nobody can name an owner for is usually the one that gets hacked.
Services related to this guide
Thinking about something similar for your business?
Talk Through Your Requirements