PHP2Shell: two holes, one cure

Almost everyone running PHP on the web is, right now, a single request away from losing their server to someone else. That's the worst news of the month. And whoever sends that request doesn't even need a password. I'm not exaggerating. On 21 October 2026 the PHP project shipped 8.5.12, 8.4.27, 8.3.36 and 8.2.35 as emergency security releases. They close two holes, CVE-2026-109618 and CVE-2026-109619. Both have a CVSS v4.0 score of 9.2, both are rated "critical", and both allow remote code execution without authentication. CISA has named the pair "php2shell".

First, let me list my sources: everything below comes from PHP's own announcement, the security advisories on GitHub, CISA's alert and what the security press has reported. I haven't tested anything myself. I'm not going to explain how the holes work inside either, because this piece isn't here to give attackers directions. It's here to shut the door on your server. If you're curious, read PHP's advisories. Those who know, know.

Who's affected?

Short answer: pretty much everyone. According to CISA, every PHP installation that answers web requests is in on this. Apache mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed... If you didn't find yourself on that list, you probably didn't read it carefully enough.

But they're not all in the same amount of danger. PHP sees the biggest risk in mod_php. The reason is pretty scary: a demonstrated attack fires off an unauthenticated request before a single line of your application has run. So it makes no difference how up to date you keep your WordPress or your Laravel. The attack has done its job before it ever gets to that layer. Full remote code execution has been confirmed over HTTP against mod_php running with default limits in prefork mode.

People on PHP-FPM are a bit luckier, but only a bit. According to the advisory, nobody has demonstrated a complete attack against FPM yet. Underline "yet" with a thick marker. FrankenPHP and LSAPI are described as "probably affected" based on a source code review, but that isn't confirmed. Don't read that as "not my problem". Read it as "nobody has looked yet".

What happened when?

The calendar really is tight. On 20 October PHP put out a pre-announcement saying the patch would land the next day at 14:00 UTC. Distribution maintainers got the patches in advance, so your Debian, your Ubuntu, whatever you run, most likely has its packages ready. PHP 8.6.0 RC4, still in development, came out the same day with the fixes included.

CISA published its alert on 21 October, added a SIGMA detection rule on 23 October and updated it once more on 26 October. The same day it put both holes into the KEV (Known Exploited Vulnerabilities) catalogue. That catalogue is the official way of telling US federal civilian agencies "you have to close this by a certain date". Many sources give that date as 29 October 2026. That's tomorrow. A whole crowd of agencies, from the NSA to Britain's NCSC, from Australia to the Netherlands, from New Zealand to Canada, put out alerts of their own. You don't often see that many countries saying the same thing on the same day.

As for who found the holes: the advisory thanks people called lcfr-hax, sagitzadik-wiz, tomash-areion and amyb-oai. BleepingComputer introduces them as researchers at Calif, OpenAI and Wiz. There are also stories doing the rounds that don't agree about who found it first and who broke the embargo. The primary source confirms none of them, and I'm not going to sell you unconfirmed gossip as news.

Have the attacks started?

They have. But here too, keep the panic in proportion. According to a BleepingComputer report dated 27 October, Adel Karimi, who heads the detection team at Perplexity, saw a successful remote code execution on a honeypot over the weekend of 24-25 October. That server was running Apache mod_php and PHP 8.4.26, in other words the version right before the patch. Earlier attempts were logged as failures. Cloudflare, Amazon, watchTowr, Hadrian, Previdian and Patchstack all reported attempts of this kind. One of the entries in Amazon's MadPot honeypots is dated 17 October, four days before the holes were made public. Make a note of that too.

On the other hand, Bitdefender said that as of 22 October it hadn't seen a single attempt in its own data. A Dutch agency also announced later that large-scale exploitation looked less likely than first thought. Don't read these two as "so there's no rush". Once a server has been taken over, optimistic statistics won't do you the slightest bit of good.

There are numbers on the scale as well, but they're second hand. Going by VirusTotal estimates, BleepingComputer writes that there are more than 5.1 million PHP servers exposed to the internet. According to some reports, a number of government sites, cyber.gov.au among them, and a credit union in the US were taken offline for a while to get patched. Read these as estimates and reports, not confirmed facts.

What should you do?

This section is short, because what PHP says is short too: update. According to PHP, that is the complete fix, and the only one. The advisory also lists a few temporary settings that reduce the risk, but PHP says plainly that they don't make the system safe. Think of them as sticking plasters to get you through until you've patched. They are not a substitute for surgery. If you want the details, look at PHP's own advisory, but rather than spending time there, spend that time updating the server.

If you don't know what's running on your setup (pretty normal on shared hosting), ask your hosting company. Find out which PHP version you're on and in which mode. If the answer is mod_php, you're at the very front of the queue.

Bad news for those on old versions: PHP 8.1 and older get no updates from the project. There are some backports with minimal fixes for 7.4, 8.0 and 8.1, but relying on them is like fixing the brakes on an old car with sticky tape. CISA's advice here is uncompromising: if you can't patch right away, or you're on 8.1 or older, take the system offline. Yes, switch it off. If your site is down for a day you lose a day. If it gets taken over you lose a lot more.

Those on 8.2 shouldn't relax either. That version got a patch this time, but it reaches end of life on 31 December 2026. If a similar story breaks two months from now, you won't be so lucky. Since you've got your hands on the server anyway, now's exactly the right time to move up a version.

And there's one detail you ABSOLUTELY need to know: two more, separate PHP holes were announced in the same days. CVE-2026-115560 is an edge case to do with session upload progress (an informational advisory came out on 23 October), and CVE-2026-111497 has to do with Brotli and was fixed in the Windows rebuilds (8.x.y-1) on 26 October. These are not part of PHP2Shell. The headlines mix them all up together. Don't you mix them up. If you run PHP on Windows, check for that "-1" build as well.

And as before any update, take your backup before this one. They say haste is the devil's work. Hasty updates sometimes come with a broken config file thrown in.

My verdict

If you ask me, this is one of the most serious web security incidents of the year. I don't need to dream up a disaster scenario to say so. PHP's own advisory does the job: an attack that needs no authentication, fires before the application does and is confirmed on default settings. Add the KEV listing to that, plus a successful exploit seen on a real server. Credit where it's due to the PHP team, though: they pre-announced, gave the distributions the patch in advance, patched all four of the four supported versions on the same day and wrote out in plain words which setups are at how much risk. That's a pretty good example of giving people the right information without causing a panic.

The job is clear, and there's only one: connect to your server, check your PHP version, update. Reading this piece took you five minutes. The update will most likely take less. If you're still reading, stop, go and update!

Bye for now.