If your business has a website, there is a fair chance it runs on PHP. W3Techs puts PHP behind around seven in ten websites whose server language it can detect. WordPress does. So do WooCommerce, Joomla, Drupal, Magento and plenty of booking systems, intranets and customer portals. On 21 October 2026, the people who maintain PHP released emergency fixes for a critical PHP vulnerability, two bugs now nicknamed PHP2Shell, and said plainly: “There are no complete mitigations, updating is the only safe choice.”
This PHP vulnerability is a flaw in PHP itself, not in WordPress, and that distinction matters. Updating your website, your theme or your plugins does nothing here. The fix has to happen on the server, and for most small businesses that means someone else has to do it. This post explains what changed, whether it affects you, and what to ask for this week.
What actually changed
Two flaws in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619, let an attacker send a specially crafted request to a web server and run their own code on it. No password, no login, no need to find a weak plugin first. Both are rated 9.2 out of 10 on the industry severity scale, which is as serious as web server bugs get.
In plain English: PHP can be knocked off balance while it is still setting up a request, and the clean-up code trusts data that was never properly built. The second bug lets leftovers from one visitor’s request leak into the next one. Either way, the attacker ends up running commands on your server as if they were the website.
PHP fixed this in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The NCSC issued an alert the same day, and so did CISA in the United States. Security researchers at watchTowr reported exploitation attempts from 21 October, the same day the fix came out. Attackers read these advisories too.
Does this PHP vulnerability affect you?
The NCSC’s position is blunt: “Organisations using any version of PHP are affected.” Here is how that breaks down for a typical business with 20 to 200 staff.
Your website is hosted by someone else (most businesses). You are affected by this PHP vulnerability, but you cannot fix it yourself. Your hosting provider has to update PHP on the server and restart it. Good hosts did this within hours. Some were still waiting for builds from their own suppliers two days later. You need written confirmation, not an assumption.
You run WordPress, WooCommerce or another PHP-based system. Same answer. The flaw is underneath your website, not in it. A fully updated WordPress on an unpatched server is still exposed.
You have PHP you have forgotten about. This is the one we see most often when we onboard a new client: an old intranet, a booking tool a former supplier built, a phone system’s web portal, a printer or firewall admin page. The NCSC’s advice specifically covers “appliances and services that may bundle PHP”. If it has a web page and nobody owns it, assume it is affected until someone proves otherwise.
You are on PHP 8.1 or older. PHP’s own words: these versions “no longer receive updates from the PHP project”. There is no official fix. Some server operating systems have issued their own patch, but otherwise the only route is to upgrade. PHP 8.2 also reaches end of life on 31 December 2026, so a server on 8.2 is buying weeks, not years.
Your server says it is on an old version but your IT team says it is patched. Both can be true. Ubuntu, Debian and Red Hat fix bugs without changing the version number, so a patched server can still report an old-looking version. Ask for the evidence, not the number.
What to do this week
The NCSC published six priority actions for this PHP vulnerability. Translated for a business owner rather than a server administrator, they come down to this.
- Ask your host or IT provider one question in writing: “Has PHP on every server running our sites been updated to a fixed version and restarted, and which version is it now?” A straight answer names the version and the date. “We’re monitoring the situation” is not an answer.
- List everything that might run PHP, not just the main website. Intranets, portals, booking systems, appliances. The NCSC says to prioritise anything reachable from the internet first, then internal systems.
- Update and restart. If you manage your own servers, update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restart every PHP worker. The fix does not take effect until the restart.
- If something cannot be updated now, take it offline or cut its internet access until it can be. PHP has published temporary settings that reduce exposure, and the NCSC points to them, but PHP is clear that they “do not make an installation safe”. A firewall in front of the site helps a little. It is not a fix.
- If a system sat exposed for days before it was patched, have someone check it for signs of compromise before you move on. The NCSC’s advice is to look first for anything an attacker may have left behind to get back in, then update, and to use an NCSC-assured incident response provider if you are not confident doing that yourself.
One more thing. PHP released a follow-up advisory on 23 October about a related PHP vulnerability, so this will not be the last update. Whoever looks after your servers should expect more patches and apply them quickly.
What we are doing for clients
For the businesses we look after, this week is about two lists. The first is every website and web-facing system we know about, checked against the fixed PHP versions, with the host’s confirmation in writing where the hosting is someone else’s. The second is the forgotten PHP: anything in the estate with a web interface, matched against the published list of affected products, then patched or switched off.
That is the unglamorous part of security. No new product to buy, no clever tool, just knowing what you have and keeping it updated. If you are not sure whether anyone has done that for you, a free IT health check will show you where PHP is hiding in your business and whether this PHP vulnerability reaches it, and our vulnerability management service keeps it found.
