PHP2Shell (CVE-2026-109618 / CVE-2026-109619): what it is and what to do

On 21 October the PHP project shipped emergency patches for two critical vulnerabilities. Either one lets an attacker run code on a web server with a single request and no login. Someone was already using one of them four days before the patch existed.

This is what we told our own clients, written for business owners rather than security teams. Last updated 22 October 2026.

The thirty-second version

Two flaws in PHP itself: CVE-2026-109618 and CVE-2026-109619. Rated 9.2 out of 10.
Unauthenticated remote code execution — no password, no click, one request.
Fixed releases: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, with backports for 7.4, 8.0 and 8.1.
Nearly every business website runs PHP. Every WordPress site does.
Update now. Don’t wait for evidence that you personally are being attacked.

Not sure whether this affects you? Request a free scan and we’ll check what your site exposes publicly, then tell you where you stand. No charge, no obligation, no sales call attached.

What actually broke

These are not WordPress bugs or plugin bugs. They sit in PHP itself, the layer underneath whatever your site is built with, which is why the blast radius is so wide. Patching your plugins does nothing for this.

CVE-2026-109618 is a memory-handling failure. When PHP runs out of memory partway through a request, some of that request’s data is left half-written. The cleanup routine then treats that invalid data as though it were valid. An attacker who can reliably push a server to that point gets influence over what happens next.

CVE-2026-109619 is stale state. Internal data belonging to one request can survive after the memory holding it has been released, and a later request handled by the same worker process can pick it up before it has been reset.

Every PHP setup that serves web requests is in scope — mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. Sites running mod_php are the most exposed, because the PHP interpreter sits inside the web server process itself.

“PHP2Shell” is a nickname the security industry attached to this. It is not PHP’s official name for the issue, so don’t be thrown if your host doesn’t recognise the term. The CVE numbers are what matter.

How it unfolded

17 October — Amazon’s honeypot network records an exploitation attempt, four days before any public disclosure and before a patch existed.
21 October — PHP releases emergency updates across four supported branches. Linux distributions and hosting vendors were notified ahead of the public announcement.
22 October — Palo Alto confirms all PAN-OS and Panorama versions are affected with no fixed release yet. Fortinet and Cisco are still assessing.

How to check — and why the version number will probably mislead you

The obvious check is to find your PHP version and compare it against the fixed releases above. On most business hosting, that check gives you the wrong answer, and this is the part we have spent the morning explaining.

Most small-business websites sit on shared hosting built on cPanel and CloudLinux. Those platforms don’t ship PHP’s upstream release. They take the security fix, apply it to their own build, and deliberately keep a version number below PHP’s. A fully patched CloudLinux server can report PHP 8.4.26 when the official fixed release is 8.4.27. It is patched. The number simply doesn’t say so.

Which means the version string tells you very little on its own, in either direction. What settles it is the package changelog, and on shared hosting you can’t read that yourself.

So ask your host this, word for word:

Does the PHP build serving my account include the fixes for CVE-2026-109618 and CVE-2026-109619? Please confirm from the package changelog rather than the version number.

Asking by CVE number gets you a real answer. Asking “am I on the latest PHP?” gets you a yes from the host who patched and a yes from the host who didn’t.

If you’re on shared hosting

Send your host the question above and keep the reply. If they can’t answer it in plain terms within a day, that itself is information about your host.
If your control panel lets you choose a PHP branch, check whether a newer build has appeared and switch once your host confirms it carries the fix. Test the site afterwards — a PHP branch change can break older plugins.
If you’re on PHP 8.1 or older, there is no supported upstream fix. You need your host to move you to a supported branch, and that is now urgent rather than housekeeping.
Update WordPress core, plugins and themes while you’re in there. It isn’t the fix for this, but anyone scanning for one vulnerability will happily use another.

If you run your own servers

Inventory every PHP runtime you have, not just the obvious website. Intranets, internal tools, forgotten staging sites and vendor appliances all count.
Prioritise anything running mod_php, then anything reachable from the internet.
Install the fixed release for your branch, then restart the workers. Apache, PHP-FPM and LiteSpeed all keep long-lived processes that go on running the old code until they’re restarted. Patching and not restarting is one of the most common ways people believe they’re fixed when they aren’t.
Retest afterwards rather than assuming.
Anything you genuinely cannot patch should come off the internet until you can. That is the UK NCSC’s advice as well as ours.

A warning about firewalls and virtual patching

Cloudflare has deployed rules covering known exploit traffic, and they apply to free plans as well as paid. Imunify360, common on cPanel hosts, has added rules too.

Useful, but do not treat either as the fix, for three reasons. The published rules target the known exploit shape, and one of the two flaws has an additional path that was not covered by rules at the time of writing. On LiteSpeed servers specifically, the Imunify360 rule logs matching requests rather than blocking them. And exploit code evolves faster than rule sets.

Virtual patching buys you hours. Only the PHP update closes the hole.

Questions we’re being asked

Is anyone actually exploiting this? Yes — an attempt was recorded on 17 October, before disclosure, and honeypots picked up activity on the day of release. As of 22 October it has not been added to CISA’s Known Exploited Vulnerabilities catalogue. Treat that as a lagging indicator rather than reassurance.

Our site is small. Why would anyone target us? Nobody is targeting you. Mass scanning doesn’t select for company size — it sweeps address ranges looking for anything that answers. Small sites on shared hosting are frequently the easiest things on the internet to find.

It’s only an internal server, not a public website. Lower risk, not no risk. Anything an attacker already inside your network can reach is still in scope, and that includes a device compromised through a phishing email.

Should I take the site offline? Only if you can’t get a straight answer from your host and the site handles anything sensitive. For most small business websites, pressing your host hard today is the proportionate response.

What about our firewall or other appliances? Several vendors ship PHP inside their products. Palo Alto has confirmed PAN-OS and Panorama are affected with no fixed release as of 22 October. Check your vendors’ advisories rather than assuming an appliance is somebody else’s problem.

Sources

We’d rather you verified this than took our word for it:

Request a free scan

If you’ve asked your host and don’t like the answer, or you don’t know where to start, we’ll run a free external scan of your site and tell you what we find — what’s exposed, what’s running, and anything that needs attention beyond this one issue. It costs you nothing and there’s no obligation attached.

We’ll be straight about the limits, because it matters here. An external scan shows what your site presents to the internet. For this particular flaw, confirming a backported fix still means getting an answer out of your host — so we’ll help you ask the right question and make sense of the reply.

Request your free scan and tell us what you’re running. We’ll come back to you the same day.

If it turns out your question is bigger than PHP — whether anyone is actually watching your systems, when your backups were last tested, what else is quietly out of date — that’s what Groundwork is for: a fixed-fee audit that documents what you have and tells you what to fix first.