On October 21, the PHP project published a security advisory for two critical remote code execution vulnerabilities and shipped fixes the same day. You can read the PHP announcement archive yourself. The patched releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Both flaws are rated 9.2 on the CVSS v4.0 scale, which is about as serious as this gets.
This matters to you if you have a website. Not if you have a development team. If you have a website.
What actually happened
Researchers at Wiz found the first of the two bugs in August and reported it to the PHP security team. Their write-up names the flaws CVE-2026-109618 and CVE-2026-109619 and calls the combined exploit PHP2Shell. The short version: the bugs sit in PHP itself, not in your site’s code. An unauthenticated attacker could run code on the Server or read sensitive memory, including passwords, tokens, and API keys. Wiz demonstrated this against WordPress, Drupal and Joomla images in testing. The researchers used frontier AI models to chain the flaws into working exploits, which is its own story and one I will come back to.
As of the disclosure, there was no confirmed exploitation in the wild. That did not stop several governments from pulling public services offline as a precaution while they patched. The National reported that the Netherlands, Finland, France, and Australia all did so.
How do I check my PHP version?
Log in to your site. If you run WordPress, go to Tools, then Site Health, then Info, then Server. The PHP version is listed there. Your host’s control panel will show it too.
Then compare it to the patched releases above. If you are on 8.5, you want 8.5.12 or later. If you are on 8.2, you want 8.2.35, and you should also know that PHP 8.2 reaches end of life on December 31, 2026. If you are on 8.1 or older, the PHP project no longer ships security updates for you. That is not a patch problem. That is a planning problem.
What should I ask my host?
WordPress told site owners to update PHP immediately and to check with their host, because many hosts were already pushing the update and adding firewall rules. Notably, WordPress said no WordPress update was needed, since the flaws affect any server running PHP.
So the email to your host is short. Which PHP version is my site running right now? Have you applied the October 21 security release? If not, when? Keep the reply.
If nobody owns that question in your business, that is the finding. A website is infrastructure. Someone has to be responsible for patching it in a bad week, and if the answer is the guy who built it in 2019, you don’t have a host relationship; you have a hope. This is the sort of thing a web development partner is for: knowing what version you run before the advisory lands, not after.
The part worth sitting with
Two memory bugs survived in PHP for roughly a decade. Humans had looked. Then models were pointed at the same code, and the bugs became working exploits within weeks.
Defenders got there first this time. Plan on the assumption that next time it is a coin flip, and that the gap between disclosure and exploitation keeps shrinking. The practical response is not panic. It is knowing who patches your systems, how fast, and how you would find out. If you cannot answer that today, it belongs on the list with your other unowned risks, and that is a conversation worth having before the next advisory, not during it. If you want help drawing that line, that is part of what consulting engagements are for.