On Wednesday 21 October 2026, councils, government departments, universities, and businesses around the world took their websites offline. The cause was two critical vulnerabilities in PHP, the programming language that runs most of the web. In the UK, sites belonging to Edinburgh, Oxford, and Bristol councils were among those taken down, and the National Cyber Security Centre (NCSC) advised website owners to take their systems offline if they could not act on the problem straight away.
If your business has a website, this one is worth five minutes of your time.
What happened
On Tuesday 20 October, the PHP security team gave advance notice of two critical vulnerabilities, now tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed “PHP2Shell”. Both are rated 9.2 out of 10 for severity. Either one can allow an attacker to run their own code on a web server without needing to log in, which in practice can mean full control of the website and potentially the server behind it.
Details of the flaws leaked before the planned disclosure, and security firms have reported that attackers are already trying to exploit them. PHP released fixed versions on the afternoon of 21 October: 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
The flaws had been sitting unnoticed in PHP’s code for more than a decade. They were found by security company Wiz using AI tools, which is a sign of things to come: AI is making it faster to find weaknesses, and attackers have access to the same technology as defenders.
Why this matters to small businesses
PHP underpins roughly three quarters of websites whose technology can be identified. It sits underneath WordPress, Drupal, Joomla, and Magento, so if your website runs on any of these, it runs on PHP, whether or not you have ever heard of it.
Most small businesses don’t manage their own web servers. A hosting company or web developer does, which means you are relying on them to have patched. Many will have done so already, but not all, and some sites are running on versions of PHP that are no longer supported at all.
Is your website affected?
Any website running a version of PHP older than the fixed releases above is exposed until it is updated. Versions 8.1 and older are a particular concern: the PHP project no longer issues updates for them. Some hosting providers and Linux distributions add the fixes to older versions themselves, but you cannot assume yours has.
Security researchers estimate that around half of all PHP websites are on older versions. If your site was built some years ago and hasn’t been looked at since, it is likely to be one of them.
What to do now
- Ask your hosting provider or web developer today. Ask two questions: has PHP been updated to a fixed version, and which version is my site running? Get the answer in writing.
- Check the version yourself if you use WordPress. Go to Tools, then Site Health, then the Info tab, and look under Server for the PHP version.
- If you are on PHP 8.1 or older, plan an upgrade. Ask your provider whether they have applied a backported fix. If they haven’t, your site needs moving to a supported version. Note that PHP 8.2 itself stops receiving security fixes on 31 December 2026, so if you are upgrading, go further than that.
- If you can’t get confirmation, follow the NCSC’s advice. Taking a site offline or into maintenance mode for a day is far cheaper than recovering from a compromise.
- Look for signs of compromise. Check for administrator accounts you don’t recognise, unexpected pages or redirects, unfamiliar files, and warnings from your security plugin or host. If anything looks wrong, treat it as an incident rather than tidying it up quietly.
- Make sure you have a recent, working backup stored away from the website itself.
If you manage your own servers, apply the official PHP release or your Linux distribution’s updated packages. Interim configuration changes can reduce exposure to one of the flaws, but updating is the only complete fix.
A wider lesson: know what you depend on
The organisations that coped best this week were the ones that already knew which of their systems ran PHP, which versions they were on, and who was responsible for patching them. Many others found out the hard way that they had forgotten servers, old microsites, or suppliers they couldn’t reach.
For organisations working to ISO 27001, this is a live test of control A.8.8 (Management of technical vulnerabilities) and A.5.22 (Monitoring, review and change management of supplier services). If your web host or developer couldn’t tell you quickly whether you were exposed, that is worth raising at your next supplier review, and worth recording as a lesson learned.
Need help?
If you’re not sure where your website stands, or you’d like help putting supplier and vulnerability management on a firmer footing, get in touch with Taylor Baines.
