PHP2Shell: Patching Closes the Door. It Doesn't Tell You Who's Already Inside.

If you run a website, an online store, a client portal or a business application, there is a good chance PHP is somewhere underneath it. This week that matters, because two critical flaws in the PHP engine itself, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed PHP2Shell, are being exploited. I want to walk through what is actually established, where the sources disagree, what I think the worst case looks like, and the one idea I'd ask every business owner to take away. I'm writing this on October 27, and parts of it will date quickly.

What is established

Both flaws allow an unauthenticated attacker to run code on a server over the network, with the privileges of the web worker. They are rated 9.2 out of 10 on the CVSS v4 scale. They affect PHP installations that serve web requests, whether through Apache's mod_php, PHP-FPM, php-cgi, FrankenPHP or LiteSpeed, and PHP itself considers Apache with mod_php the highest risk. The earliest affected release is PHP 5.4, from 2012.

PHP shipped fixes on October 21 in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older no longer receive routine upstream updates. Limited source patches exist for 7.4, 8.0 and 8.1, but not ready-to-install builds from the project itself. PHP's position is that no configuration change fully mitigates the flaws and that updating is the only complete fix.

On exploitation, the timeline matters. Amazon's threat intelligence team reported an exploitation attempt on October 17, four days before the patches. Details leaked on October 20, a day before PHP's emergency release and two days ahead of the planned disclosure. Cloudflare has reported millions of exploitation attempts since disclosure. On October 24, a researcher at Perplexity recorded confirmed remote code execution against a honeypot, which a second researcher independently confirmed. And on October 26, CISA added both flaws to its Known Exploited Vulnerabilities catalog, with a federal patching deadline of October 29. The Canadian Centre for Cyber Security has also issued an alert, AL26-026.

Governments did not wait. The UK reported dozens of government services offline, French prefecture websites were taken down by the Interior Ministry, and sites in the Netherlands, Nepal and Australia were reported offline as well. When governments pull their own services rather than risk running unpatched, you are seeing a worst-case decision made in real time.

What is disputed

Exposure numbers range from roughly 1.3 million exposed hosts to more than 37 million internet-facing systems running PHP or PHP-related software, depending on who counted and how. I'd treat all of them as "millions" and not argue about the decimal.

How easy it is to exploit is also contested. The researchers who found the flaws say the chains are reliable under default configurations and demonstrated remote code execution against default installs of common applications. Rapid7, which reviewed the public proofs of concept, found that each works only for a specific combination of operating system, PHP version and web server, and the published CVSS vector itself rates the attack complexity as high. The first confirmed in-the-wild success came against a configuration the researcher himself called favorable.

And attribution is unsettled. One firm has linked low-volume scanning to a suspected North Korea-linked operator, with moderate confidence and no independent verification. Another firm initially tied a serious compromise of a European government agency to PHP2Shell, then retracted the link because it could not confirm how the attacker got in. I would not repeat either claim as fact.

The worst case

The worst case here is not that the internet breaks. It is a sequence, and every step of it is ordinary. I'm describing a plausible upper bound, not a prediction, and nobody has shown that all of these steps are happening at scale.

First, someone turns the working chains into a reliable, automated exploit. Everything needed to try is public. Second, mass scanning finds the long tail: millions of servers, many of them small business sites, shared hosting accounts and applications nobody has touched in years. Third, attackers install web shells and then read the files on the server, which often contain database passwords, mail credentials and cloud keys. Fourth, from a compromised web server, they move sideways into whatever it can reach, which in many small organizations is much more than it should. Fifth, because a patch does not remove a web shell or a stolen password, access survives the fix. And sixth, a large number of servers running PHP versions that no longer get upstream fixes stay exposed for years.

Three things make this more dangerous than the usual critical bug. The flaw sits in the runtime, so it can be hit before your application's own security code ever runs. It is hidden inside other software, a point CISA made explicitly: PHP is often a component, so you may not know you have it. And the window before the patch was real, not theoretical.

There is also a sign of where this is heading. The researchers have said they used large language models to help audit PHP's code, and the first flaw was found on August 1 and reported to PHP ten days later, about ten weeks before the fix shipped. Sources disagree on which AI models were involved, but the direction is clear. Defenders and attackers are both finding bugs faster, and the gap between "found" and "fixed" is now the exposure.

What limits the worst case is just as real. Exploitation is not trivial, public proofs of concept are not broadly reliable, and so far I have not seen credible evidence of mass compromise. That is a reason for urgency, not complacency. It is the window you are in.

Patching is not the same as clean

Here is the part I care about most, because it is the part that investigators see and patch notices don't mention. A patch closes the door. It does not tell you who is already inside.

If you had an unpatched, internet-facing PHP server at any point from October 17 onward, patching is step one, and step two is deciding whether it was compromised. Before you restart or rebuild anything, preserve what you can: web server and PHP logs, a list of running processes, and a snapshot of the server. Restarting and cleaning can destroy the only evidence of what happened.

Then look for what attackers actually leave behind. CISA's guidance is to watch for PHP worker processes launching shells or downloading tools, which should never happen on a healthy server. Look for new or recently modified files in the web directories, new administrator accounts in your content management system, unexpected scheduled tasks, and outbound connections you cannot explain. And treat every secret stored on that server as potentially exposed: database passwords, API keys, mail credentials. Rotate them. A clean-looking server with the old passwords still on it is not clean.

Lessons, obvious and not

The obvious one: update to a fixed version and restart every worker. If you cannot, CISA's advice is to take the system offline or restrict access until you can, and a web application firewall may buy time but is not a fix.

Second: you cannot patch what you cannot see. This is the same lesson as the fridge controllers, a different device. Most organizations can list their servers and laptops but not the PHP buried in a plugin, a control panel or a vendor's appliance. Inventory is a security control.

Third: ask who is responsible. If your site is hosted, managed or built by someone else, the question for this week is simple and fair: which PHP version are we on, has it been updated to a fixed release or retired, and has anyone checked for compromise since October 17? Get the answer in writing.

Fourth: end-of-life is a decision, not an accident. A site running PHP 8.1 or older with no vendor support is a choice to carry that risk. Make it deliberately, or retire the site.

Fifth: decide in advance what you would switch off. The governments that pulled sites offline had a plan, or learned the hard way that they needed one. Availability is the first thing you trade for safety, and the time to decide what is expendable is before the incident, not during it. In my CSR5 framework, that is Resiliency.

Sixth: compensating controls buy hours, not safety. The temporary settings published for these flaws reduce some attack paths and leave others open. Use them to bridge to a patch, not to avoid one.

The takeaway

When a vulnerability this broad lands, the loud question is whether you have patched. The quiet question, and the one that decides your outcome, is whether anyone got in before you did. Inherent risk is what the technology hands you. Residual risk is what remains after your controls actually work, and this week is a test of whether yours do. Patch, then check, then rotate. And write down who owns that answer, because next time the clock will be shorter.