On 21 October 2026 the PHP development team released a fix for two security flaws, now known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619). PHP is the language that runs most websites, including every site built on WordPress, Joomla or Drupal. The flaws let an attacker run commands on a site's server remotely, without logging in and without a password. Both are rated 9.2 out of 10 for severity.
The fix came out a day earlier than planned, because details about the flaws leaked onto online forums before it was ready. Amazon reported that its monitoring systems caught an attempt to exploit the flaw on 17 October, four days before the fix was published. Researchers at Wiz, at Calif and at OpenAI each found the flaws independently in August.
Israel's National Cyber Directorate advised organizations to check their systems and update them quickly, and in some cases to consider taking exposed servers offline until they are patched.
Which sites are exposed
Any business with a website that runs on PHP: an online shop, a site with an order form or appointment booking, even a plain WordPress brochure site. Wiz estimates that about 70% of websites use PHP. That does not mean 70% of sites have been breached. The risk depends on the PHP version installed on the server and how it is configured.
The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. A server still running PHP 8.1 or older is in a harder spot: those versions no longer get official security updates, and the PHP team only published a source-code patch for them, which someone has to install by hand.
The point business owners miss is that updating WordPress, the theme or the plugins does not close the hole. The flaw sits in the software running underneath the site, on the server itself. A business that clicked "update all" in its WordPress dashboard yesterday can still be exposed.
Checking with your hosting company
Most small businesses don't run their own server. The site lives with a hosting company, and that is where the update has to happen. The thing to do this week is contact them and ask for written confirmation that the PHP version on your server has been updated to one of the fixed releases, and that the services were restarted afterwards. Without a restart the fix doesn't take effect.
If a developer or agency built the site and manages it for you, ask them instead. Ask about old sites that are no longer in active use too, such as a landing page from a finished campaign or a previous version of the site that is still online. They run on a server as well, and they can be the way in.
Businesses whose site sits behind Cloudflare got a first layer of protection: the company switched on rules for all its customers that block the known attack methods. That protection is temporary and does not replace updating the server.
If the site was already breached
Installing the update closes the hole, but it doesn't remove an attacker who is already inside. Signs worth checking: files nobody uploaded, new admin users in WordPress, redirects to unfamiliar sites, or unusual activity in the server logs. The hosting company can check most of this.
Anyone who finds a sign of a break-in should assume the attacker left a way back in. The advice in that case is to restore the site from a backup taken before the breach, and only after PHP on the server has been updated. A site that collects customer details, orders or payment information should get this check first, because that is the data attackers are after.