PHP shipped emergency fixes on 21 October 2026 for two critical, unauthenticated remote-code-execution bugs, CVE-2026-109618 and CVE-2026-109619, together nicknamed PHP2Shell. If your server runs PHP 8.2 through 8.5 and serves web requests (WordPress, a Plesk or cPanel panel, a custom app) and isn't already on 8.2.35, 8.3.36, 8.4.27, or 8.5.12, it's vulnerable right now, and researchers have already seen people probing for it.
What Is PHP2Shell, And What Actually Shipped On October 21?#
PHP2Shell is the nickname for two separate RCE bugs patched in the same release. CVE-2026-109618 is memory corruption during out-of-memory handling. CVE-2026-109619 is a use-after-free bug involving state left over between requests. Both carry a CVSSv4 score of 9.2, and neither requires authentication. The official PHP security advisories describe the mechanics in full.
PHP posted an advance notice on 20 October, then moved the fix release itself up a day, to 21 October at 14:00 UTC, after the CVE identifiers leaked early. Fixed versions are 8.2.35, 8.3.36, 8.4.27, and 8.5.12. PHP 7.4, 8.0, and 8.1 are past routine support, so the project only shipped limited source backports for those.
Rapid7's analysis rates every configuration that serves web requests as at risk:
- PHP-FPM
- Apache's mod_php (rated the highest-risk setup)
- php-cgi
- FrankenPHP
- LiteSpeed
At WebEpex we pulled the PHP version on every client VPS we still have server access to within hours of the advisory, the same day it went out, even on the handful that aren't ours to patch directly.
Does This Matter If You Don't Run PHP Yourself?#
Depends on what's actually on your server, not what you built. If your stack is genuinely Node.js, Next.js, or another non-PHP runtime with nothing legacy sitting beside it, this specific pair of CVEs doesn't touch you, the same way last month's Next.js vulnerability didn't touch anyone running pure PHP.
But plenty of businesses run PHP without quite realizing how much of it: a WordPress blog bolted onto an otherwise modern stack, a client portal built years ago, a Plesk or cPanel panel that ships its own bundled PHP regardless of what your main app uses. If any part of your infrastructure answers a web request through PHP, this is your week to check, not next quarter's.
The Honest Trade-offs#
The good part: fixes already exist for every actively supported branch, and they're free. Cloudflare pushed WAF rules for known exploit patterns to every plan, including free, so there's a stopgap even before you patch.
The real risk, though, is already live. Amazon's threat intelligence team logged a probe against its own honeypot on 17 October, four days before the public fix, and saw more attempts on 21 October that look like multiple separate actors.
Exploit code is circulating publicly, though researchers haven't verified it works, and some of it is reportedly booby-trapped with its own malware. Panels add a second layer of risk: Plesk's own internal engine needed a separate patch beyond the PHP update itself, so updating PHP alone isn't always the whole fix if you run a panel. If your VPS is managed for you rather than self-administered, the kind of setup we looked at in our DigitalOcean managed agents piece, confirm with your provider that this round of patching is actually their job and not a gap neither of you is covering.
How We're Handling It At WebEpex#
We don't run PHP for our own apps. Our stack is Next.js and Node.js on self-hosted VPS instances behind PM2 and Nginx, by design, specifically so a language-specific emergency like this one doesn't touch our own infrastructure at all.
It does touch some of our clients' though, mostly WordPress sites we inherited mid-build or still maintain alongside a newer app. For every one of those, we checked the PHP version first (php -v plus the panel's own settings page when there is one), then updated through the distribution's or panel's own repository rather than a manual source build.
We restarted both PHP-FPM and the web server in front of it, since restarting one without the other leaves the old binary serving requests, the same discipline we wrote about restarting services properly in our n8n security patch coverage. One client's Docker setup had a second PHP copy sitting inside a sidecar container that the host-level update never touched. We nearly missed it on the first pass, and that's the mistake worth repeating here: check every container, not just the host.
What I'd Tell A Client Asking About This#
Run php -v on every server you control today, not this week. If you're below 8.2.35, 8.3.36, 8.4.27, or 8.5.12, patch now through your distribution's or panel's own repository. If you're on PHP 8.1 or earlier, that's a second problem on top of this one: talk to whoever manages your server about an upgrade, because you're relying on backports for issues like this from now on. If you genuinely have no PHP anywhere, you can skip this one entirely and get back to your actual week.
If you want a second set of eyes on whether anything you're running is exposed, send me what's on your server and I'll tell you straight what needs patching first. No pitch attached. cal.com/webepex/growth-review
