On 21 October 2026 the PHP project shipped an emergency security release for two vulnerabilities that let an attacker run code on your web server without logging in to anything. They have been nicknamed PHP2Shell, they both carry a CVSS v4.0 score of 9.2, and CISA added them to its Known Exploited Vulnerabilities catalog five days later. That last part is the one that matters: this is not theoretical. It is being used.
What makes this different from the usual plugin vulnerability is where it lives. Every piece of security advice a WordPress owner has ever been given — keep core updated, keep plugins updated, use a strong password, add two-factor — does nothing here. The flaw is in PHP itself, the layer underneath WordPress. A perfectly maintained, fully patched WordPress site on an unpatched PHP is just as exposed as a neglected one.
What the two bugs actually are
CVE-2026-109618 is a memory corruption bug in how PHP handles running out of memory. When a request exhausts the memory limit, request data can be left partially initialised, and the cleanup that follows can treat that half-built data as if it were valid.
CVE-2026-109619 is a use-after-free involving state that outlives the request it belonged to. Memory tied to one request can be freed and then still be reached by a later request handled by the same worker process.
Both end in the same place: an attacker who can send requests to your site may be able to execute their own code on your server. No account, no password, no stolen key. Just HTTP requests, which is exactly what a public website exists to accept.
They affect every PHP installation that serves web requests — Apache with mod_php (which the PHP team rates as highest risk), PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. There is no common WordPress hosting configuration that sits outside that list.
The versions that fix it
The patched releases, listed on php.net, are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If your server runs any of those or newer, you are patched against these two CVEs.
If it runs PHP 8.1 or older, there is no fix coming. Those branches no longer receive upstream security updates, so the only route off this vulnerability is a version upgrade — which, on a site with ageing plugins and a theme nobody has touched in years, is real work rather than a button. CISA’s own guidance for systems in that position is blunt: take them offline until they can be updated.
This is where a lot of Malaysian SME sites are sitting right now. PHP 7.4 and 8.0 are still extremely common on older shared hosting accounts, and the hosting dashboard will happily keep reporting that everything is fine.
The mitigations are not a fix
Two things circulated quickly in the days after disclosure, and both are worth being precise about.
The first is session.upload_progress.enabled=0. The PHP team does recommend that setting, but for a different and separate issue — CVE-2026-115560, disclosed on 23 October, which requires an unusual configuration and is rated an unlikely risk. It is not a fix for PHP2Shell. Setting it and declaring the job done is a mistake.
The second is a web application firewall. A WAF is genuinely useful as interim cover while you arrange patching, and CISA suggests exactly that. But it is a filter in front of the hole, not the hole closed. The PHP team’s own wording is that mitigations reduce exposure without making an installation safe.
Only the patch fixes it.
What to actually do this week
- Find out what PHP version you are on. Not what you think you are on — what the server reports. Every site, every staging copy, every forgotten subdomain.
- Patch to a fixed release, or upgrade the branch if you are on 8.1 or older.
- Assume the window before patching was exposed. Exploitation attempts were observed before the patch shipped, so “we updated last week” is not the same as “we were never reachable.” Check for the usual aftermath: admin users you did not create, files modified when nobody was working, scheduled tasks you did not schedule, outbound traffic with no matching visitors. Our post on five signs your WordPress site is already compromised walks through each of those.
- Rotate credentials if anything looks wrong, and treat it as an incident rather than a tidy-up.
Why this one makes the case for a care plan
Here is the uncomfortable part for anyone looking after their own site.
The patch came out on a Wednesday. Attacks were already running before it landed. To have been safe, somebody had to be watching PHP’s security announcements, know which PHP version each site was on without going to look, understand that this one bypassed every WordPress-level protection in place, and be able to patch or upgrade a production server the same day without taking the business offline in the process.
That is not a thing a business owner can reasonably be expected to do between meetings. It is not a thing most web designers do either — building a site and maintaining the platform under it are different jobs. And it is specifically not something your host does for you on a shared plan, where you are usually offered a dropdown of PHP versions and left to pick.
This is the entire reason our Care Plans exist, and it is a fair test of what one is worth:
- Somebody already knows what you are running. Patching starts with an inventory. On a care plan, the PHP version, server stack and plugin set for your site are known before the advisory lands, not discovered during the panic.
- Updates are tested, not blindly applied. A PHP branch upgrade can break an old plugin. Doing it properly means a staging copy, a check, and a rollback path — which is how it gets done on a plan, instead of being postponed for months because it feels risky.
- Server-level work is actually in scope. This is the distinction between our plans. Managed WordPress covers the WordPress layer on hosting you already have. Managed WordPress + Web Server covers the server underneath it too — the layer this vulnerability lives in — which is why it is the plan we point most businesses toward.
- The backups are off-site and held separately from your host. If a server is compromised, backups stored on that same server are part of the compromise. Ours are not.
- Monitoring means you hear it from us first. Finding out from a customer, or from a Google blacklist warning, costs far more than the plan does.
A care plan is not insurance against things going wrong. It is the difference between a vulnerability being a scheduled hour of work on a Wednesday and being a week of lost revenue, a forensic recovery bill, and a conversation with your customers about their data.
If you are not sure where you stand
We will tell you honestly. If you want to know what PHP version your site is on, whether you were exposed, and whether anything got in during the window, get in touch and we will check. If something did get in, that is Emergency Rescue rather than a care plan — and once it is clean, a plan is what keeps it that way.