Most of the vulnerabilities we end up writing to clients about are in something the business chose. A plugin somebody installed, a library a developer pulled in, a product that went through procurement. This one is in the floor.
What happened
On 21 October 2026 the PHP project shipped emergency fixes for two flaws in the interpreter itself — CVE-2026-109618 and CVE-2026-109619, nicknamed php2shell. Both are rated 9.2 on CVSS v4.0. Both allow an unauthenticated attacker, with no account and no prior foothold, to run code on the web server.
The first is a memory-corruption bug in the way PHP handles running out of memory. A crafted multipart request exhausts memory while appearing to stay inside the configured limit, and the cleanup that follows treats the damaged data as valid. The second is a use-after-free: state left over from one request points at memory that has already been released. It is reachable through session upload progress, which is enabled by default, and through fatal error backtraces.
Fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Versions 7.4 through 8.1 received source backports only. Versions 5.4 through 7.3 received nothing, because they are past end of life and no longer get security fixes at all.
The worst case is Apache with mod_php, where exploitation can succeed before any of your application code runs. PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are affected too.
This is not a plugin vulnerability, and the difference matters
When a WordPress plugin or a JavaScript package turns out to be vulnerable, the response is uncomfortable but familiar: you find the version you are running, you update it, you check whether anything broke. The fix is in your hands and the work is yours.
php2shell is not in anything you installed. It is in the program that reads your code and runs it. Nothing about your site has to be unusual, out of date or badly written to be affected — a perfectly maintained application on a vulnerable interpreter is a vulnerable server. Your own update discipline, which is the thing most businesses have actually invested in, buys you nothing here.
It also means that for most organisations the fix is not theirs to apply. If you are on shared hosting, managed WordPress hosting, or a platform-as-a-service, you do not control the PHP binary. Somebody else patches it, on their schedule, and your entire remediation consists of finding out whether they have.
That is a genuinely different problem, and the honest version of the advice is uncomfortable: your exposure window here was set by a vendor's operational competence, not by yours.
The question most businesses cannot answer
Ask an organisation whether its main website runs PHP and you will get an answer in seconds. Ask where else PHP is running and the room goes quiet.
In our experience the list is almost always longer than anyone expects. The marketing microsite built for a campaign three years ago. The staging copy of the main site that was never taken down. The intranet tool a department commissioned directly. The subdomain left behind by an agency that no longer works here. The network appliance or NAS with a PHP admin interface nobody thinks of as a website.
None of those are on anyone's patch schedule, because none of them are on anyone's list. They are, however, on the internet, and a scanner does not care which of your systems you remember owning.
This is the same gap that keeps showing up in the incidents we write about: the peripheral system, the forgotten subdomain, the host that never made it onto the asset register. An interpreter-level bug is simply a more efficient way of finding out that your inventory is incomplete.
A note on the numbers, and on the timeline
Two things being reported about php2shell are worth treating with care.
The exposure figures do not agree. Tenable put the number of internet-exposed, potentially vulnerable hosts at roughly 1.3 to 1.9 million depending on methodology. Palo Alto's Cortex Xpanse reported over 22.6 million exposed instances. That is an order of magnitude apart, and the gap is almost certainly about what each is counting — hosts versus instances, confirmed versions versus plausible ones. Either number supports the conclusion that this is widespread. Neither should be quoted as the figure.
The exploitation timeline is not settled either. Tenable reported that Amazon Threat Intelligence observed a php2shell exploitation attempt on 17 October, four days before public disclosure, and described the vulnerabilities as broadly exploited by 21 October. Rapid7, writing its own analysis, said that public proof-of-concept exploits existed but that "none appears to be broadly reliable", and that it had not observed in-the-wild exploitation as of publication.
Those two accounts are not necessarily contradictory — they were written at different moments, and "an observed attempt" and "broadly reliable exploitation" are different claims. But we would not tell a client that the exploitation picture is clear, because it is not. What is clear enough to act on is that working exploitation exists, the bug class is well understood, and the gap between disclosure and mass scanning for something like this is measured in hours.
AI found this one, and that cuts both ways
The researchers credited with the discovery — a researcher going by Calif, and a team at Wiz — have both said they used AI models in the work.
That deserves more than a shrug. We wrote a few weeks ago about agentic tooling compressing the attacker's timeline in the Seoul banking intrusions, and the obvious worry was that offence gets cheaper faster than defence does. php2shell is a useful counterweight: the same capability pointed at a twenty-year-old interpreter found two critical bugs and got them fixed before they were widely burned.
The uncomfortable implication is in the middle. If bug discovery is accelerating on both sides, then the number of critical, unauthenticated, patch-now disclosures per year goes up — not because software is getting worse, but because more eyes, mechanical ones, are on it. The variable a business actually controls is not how many of these appear. It is how long it takes you to find out whether you are affected and get the fix applied. That number is now the one worth measuring.
What to actually do
Establish what you are running, today. On WordPress that is Tools → Site Health → Info → Server. On a server you control, php -v. Do it for every site and tool you own, not just the main one — and if producing that list takes longer than an afternoon, that is the more important finding.
Ask your host a specific question. Not "are we secure?" but "which PHP versions on our account have been patched for CVE-2026-109618 and CVE-2026-109619, and at what time?" Several managed hosts patched within hours of disclosure and published the timestamp. A provider that cannot answer precisely has told you something useful.
Get off the end-of-life versions, and treat it as urgent rather than tidy. PHP 5.4 through 7.3 will not be fixed for this, or for the next one. If anything you own is on those versions, it is not a patching problem any more, it is a migration problem, and the clock started some time ago.
Use the mitigations as a bridge, not a destination. Where patching has to wait, disabling session upload progress (session.upload_progress.enabled=0) and, on PHP 8.5, setting fatal_error_backtraces=0 reduce the reachable paths. They are not a fix. Rapid7's wording is worth keeping: an update containing both complete fixes is the only complete remediation.
Assume the window was open and look. For anything internet-facing that was unpatched between roughly 17 and 22 October, treat compromise as possible rather than disproven. Web server logs, unexpected files in web roots, new scheduled tasks, outbound connections from the web host — the usual places, checked properly once, is cheaper than wondering.
The summary
There is nothing a business could have done differently in its own code to avoid php2shell. That is precisely what makes it worth paying attention to: it is a reminder that a meaningful part of your attack surface is maintained by people you do not employ, running software you did not choose, on a timeline you do not set.
The two things you do control are knowing where that software is running, and how quickly you can find out whether it has been fixed. Both of those are inventory and process questions rather than technical ones, which is why they tend to go unfunded until a morning like 21 October makes them urgent.
Sources
- php2shell (CVE-2026-109618, CVE-2026-109619): Frequently Asked Questions — Tenable
- CVE-2026-109618 and CVE-2026-109619: Critical Unauthenticated Remote Code Execution in PHP — Rapid7
- Threat Brief: Critical Vulnerabilities in PHP — Unit 42, Palo Alto Networks
- Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 — Google Cloud
- PHP critical security release, October 2026: what it means for your WordPress site — Wordify
