Critical PHP security flaws: we have patched our servers, here is what to check on yours
Security update
Two critical flaws in PHP were fixed on 21 October, and attackers were already probing for them the same day. We updated our servers within hours and found no sign of any site being affected — here is what you need to do now.
What was reported
The PHP project released fixes on Wednesday 21 October for two vulnerabilities that can let an attacker run their own code on a web server without logging in. PHP's own announcement rates both as critical and tells everyone running PHP to update immediately. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
The BBC reports that the Finnish government, Edinburgh council, Wikipedia's operator and parts of the BBC itself took pages or systems offline while they dealt with it. The UK's National Cyber Security Centre has urged organisations to apply the fixes, saying that "where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated". Cloudflare's chief technology officer told the BBC that early attacks were already emerging.
The flaws were found by researchers at the security firms Calif and Wiz using AI models from OpenAI. Wiz estimates that "roughly 70%" of the internet is affected. The BBC says it could not verify that figure.
Why it matters for UK businesses
PHP runs underneath WordPress, WooCommerce, Magento, Drupal and Joomla, and under a great many custom-built websites and shops. Plenty of business owners use it every day without knowing it is there.
Older versions are the harder case. PHP 8.1 and earlier no longer receive updates from the PHP project, so a site on one of those versions needs a fixed build from its hosting company or software supplier, or an upgrade to a supported version. PHP's announcement also lists temporary settings that reduce the risk, and says plainly that they do not make a server safe. Only the update does that.
What we did
Our own e-commerce platform is built on PHP, and so is sayu.co.uk. Here is what we did on the day the fix came out:
- Updated every PHP version our servers run. Our main hosting server and the server behind our own website run several PHP versions, because some long-standing sites still need older ones. The current versions went straight to the new releases. The older ones received fixed builds from the maintainer of the Debian packages we use, who backported the same two fixes the same day.
- Restarted PHP on every server. An update only takes effect once PHP restarts, and every PHP service on both servers had restarted on the fixed code by 18:05 UK time, about three hours after the PHP project published the fix.
- Checked for signs of an attack. We went through the PHP error logs for the kind of crash these flaws cause, searched the web server logs for requests that probe the second flaw, and scanned every hosted site's files for PHP files changed since 20 October. We found no crashes of that kind and no probing requests. Every changed file belonged to our own scheduled code updates, and none contained the kind of code attackers leave behind.
We found no sign that any site on either server was affected.
What this means for your website
If your website runs on PHP, get the update made today.
If your website is on a fully hosted service, where you never manage a server, the provider is responsible for this update. Its status page or support team can confirm it has been done.
