PHP2Shell Means Your Old PHP Version Is No Longer Optional
Most local business owners I talk to have never heard of PHP, and I do not blame them. Nobody ever had a reason to tell them.
Why Old PHP Sticks Around
PHP is the language behind most small business websites, especially WordPress sites. It is also invisible. When you pay for a website, nobody tells you it runs on a language with an expiration date. You get a login, maybe a tutorial video, and the site works. The PHP version is not part of the conversation.
Then the site gets built once and handed off. The builder moves on. Nobody inside the business owns upkeep. The hosting account keeps running and the site looks fine. Nothing obvious prompts you to touch it.
Hosts keep old PHP versions selectable in their control panels. They keep them because switching can break old plugins, themes, or custom code. A broken site generates support tickets. So the default is to leave it, and I understand why. The result is a site that can sit on an old version for years after it stops receiving security fixes.
Old plugins or an abandoned custom theme block the upgrade. The version gets pinned and forgotten. WordPress keeps working on old PHP. The dashboard does not flash a warning, and the site does not slow down in a way you would notice.
What the October 21 Fix Changes
The PHP project shipped fixes on October 21, 2026 for two flaws tracked as CVE-2026-109618 and CVE-2026-109619. Researchers at Wiz named the attack PHP2Shell, and the PHP project published its own php.net advisory. The flaws sit in PHP itself and allow remote code execution without logging in, so even a carefully maintained plugin setup does not cover them.
Wiz puts the severity at up to CVSS 9.2. Nearly every PHP version back to 5.4 is affected. The researchers tested it against WordPress, Drupal, and Joomla deployments. A successful exploit can leak memory that may contain passwords, authentication tokens, API keys, and certificates. W3Techs puts PHP at about 70% of sites whose server-side language is known. Palo Alto Networks Unit 42 counted more than 22.6 million exposed PHP servers potentially at risk from these flaws.
The fixes are in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP 8.1 and older get no official release from the PHP project. Source backports exist for 7.4, 8.0, and 8.1 if you compile PHP yourself, and some distributions ship their own backports. The PHP project says plainly that updating is the only complete fix.
One detail catches people: the php.net guidance says to restart every worker after the change, because a running PHP process does not pick up the new code on its own. If your site runs in a Docker container, it carries its own PHP and needs a rebuilt or updated image.
PHP 8.2 is patched today, but it reaches end of life on December 31, 2026 and gets no security fixes after that.
Here is what I think changed. Before this release, an old but working PHP version was a slow-burn risk you could defer. For 8.1 and older, it is now an unpatched, publicly documented vulnerability. The upgrade project stops being optional.
Update, October 23: One More PHP Issue
Two days after the emergency release, the PHP project posted an informational advisory about CVE-2026-115560. The October 21 releases do not fix it. It needs a rare combination of settings and code: a site that sets session.serialize_handler to php_binary or php_serialize, then switches it to php at runtime before starting a session, with session upload progress still on. PHP calls that unlikely, no attacks on it had been reported as of October 23, and the fix will come in the next regular release rather than an emergency one.
The stopgap is one setting, session.upload_progress.enabled=0, which was already on the October 21 mitigation list. My take: if your host is patching anyway, have them turn it off in the same ticket.
Why This Is Bigger Than Your Website
Here is the part people miss. A store is not a brochure site. It holds the customer database, the login it uses to send mail, and the API keys that connect it to payment processing, accounting and shipping. Because these flaws allow remote code execution, an attacker who exploits one runs their own code on the server with the store's own access. An unpatched store is not just a website at risk, it is a set of keys to everything that store connects to. As of late October 2026, The Hacker News reported that activity on the two flaws (CVE-2026-109618 and CVE-2026-109619) was scanning and probing with no confirmed code execution, and no public report shows the exposure chained into connected systems, but that is exactly why I would not leave a store on PHP 8.1 or older, even behind a security plugin. The storefront is the door, not the prize.
How to Check Your Version
You do not need to be technical to find out where you stand.
If your site runs on WordPress, log in and go to Tools, then Site Health, then Info, then Server. The PHP version is listed there. No WordPress admin access? Then email your host one line: "Which PHP version does my site run, and is the October 21, 2026 security fix applied?" A competent support desk should answer that in one reply.
If they say 8.1 or lower, you need a plan now. If they say 8.2, confirm it is 8.2.35 or later, then plan your next upgrade before December 31, 2026.
What to Do This Month
Start with a full backup. Then set up a staging copy of the site if your host offers one. Update your plugins and active theme first, before you touch PHP. In my experience, outdated plugins are what breaks when PHP changes.
Switch the PHP version in staging. Test forms, checkout, booking flows, and any login area. If something breaks, fix it before you touch the live site. If everything works, schedule the live switch during a low traffic window and test again.
If your host still has you on 8.1 or older and cannot move you, I would start shopping for new hosting now rather than in the last week of December.
For context on why WordPress sites are frequent targets this year, read my post on the WordPress attack wave in 2026.
When You Need Help
Some sites are held together by a plugin abandoned years ago or a custom theme the original developer left behind. In those cases, switching PHP versions becomes a small rebuild project. That is normal for older small business sites, and it is fixable.
If you would rather not touch any of this yourself, that is a reasonable call, and it is exactly the kind of work I do. Get in touch with me at MySEODesk and I will help you find out where your site stands and what the upgrade path looks like, without pushing a full redesign.
