Two weeks ago I spent most of a Wednesday answering the same question from customers and reporters: are we affected by PHP2Shell? At that point the answer was "probably, but nobody knows yet." The CVE numbers had leaked, the records behind them were empty, and a good part of what was going around online turned out to be wrong.
We know a lot more now. So I want to look back at what happened, what the data says two weeks in, and what I think security teams should still be doing.
A quick recap
On October 21, PHP shipped fixes for two critical bugs, CVE-2026-109618 and CVE-2026-109619, in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Both are rated 9.2 and both can lead to unauthenticated remote code execution. The release came a day earlier than planned after the CVE IDs leaked and a proof-of-concept video was posted by mistake. The PHP security team also published source-only backports for 7.4, 8.0 and 8.1, which they didn't have to do.
Since then, a honeypot recorded a working exploit against Apache with mod_php on October 24. CISA added both CVEs to its Known Exploited Vulnerabilities catalog on October 26. And attackers chained PHP2Shell with a Linux kernel bug to get root on Palo Alto Networks firewalls whose management interfaces were exposed to the internet.
What hasn't happened, at least so far, is the mass compromise a lot of people expected. I'll get to why below.
Supported PHP got patched fast
Credit where it's due. Bitsight rescanned hosts after the release and found that 68.6% of servers on supported branches were running a fixed build within a week. On 8.4 and 8.5 it was 77%. For software this widely deployed, that's a good result. The advance notice gave people a day to get ready, the Linux distributions had patches early, and most of the PHP that's actively maintained got updated.
Some organizations went further and took sites offline until they were patched. Several government sites, including Australia's cyber.gov.au, went dark for a while on October 21. That's a blunt approach, but it shows people took the warning seriously.
Old PHP mostly didn't
This is the part that worries me. In the same Bitsight data, about 59.5% of the exposed vulnerable hosts were running an end-of-life PHP branch. Only 6.4% of those were patched after a week. PHP 7.4 was the biggest single group at around 1.73 million hosts, and 91% of them were still on unpatched 7.4 at the end of that week.
And that's with backports available. A source branch on GitHub isn't the same as a package your servers pick up on their own. Someone has to build it, test it and roll it out. For a 7.4 server nobody has touched in years, that someone usually doesn't exist.
It matches what we found in our own research. Our State of Vulnerabilities report found that the systems attackers actually go after are on average 4.4 years past end of life. Old software that still works tends to stay where it is until something forces the issue.
PHP you don't know you're running
The Palo Alto incident is the one I keep coming back to. Most people don't think of a firewall as a PHP server. It doesn't show up when someone runs php -v across the web servers. But PHP was in there, and attackers got from PHP2Shell to root by chaining it with a kernel bug.
To be fair to Palo Alto, the management interface isn't exposed to the internet by default. They say about 0.02% of their installed base had it exposed, they've contacted those customers, and fixes are out. Still, it shows two things. PHP ships inside a lot of products that never mention it. And where a vulnerable component sits matters as much as the vulnerability itself. The same bug on a forgotten test server and on the device that controls your network perimeter are very different problems.
If your PHP inventory only covers the servers your own team set up, it's missing the copies that will take longest to fix, because for those you're waiting on a vendor.
Why we haven't seen mass exploitation yet
The main reason seems to be that these exploits are fiddly. Testing against WordPress showed the exploit usually has to be adjusted for each target, depending on the PHP build, extensions, memory limits and how requests get handled. Defiant, the company behind Wordfence, reported more than 77,000 related requests from over 2,000 IPs by October 28, and no compromised WordPress sites. CrowdSec saw a lot of scanning and probing in the first five days and no confirmed compromises.
I wouldn't take too much comfort from that. CrowdSec pointed out that the number of sources attacking React2Shell grew 27 times over in a similar window. Someone only needs to package a more reliable exploit for this to change quickly. And the Palo Alto attackers showed that a determined group will put in the work when the target is worth it.
The bug had been known since 2024
The PHP Foundation's post-mortem was refreshingly open about this. The out-of-memory problem behind CVE-2026-109618 first came up during a 2024 audit by Quarkslab. Nobody had shown it was exploitable then, every proposed fix broke something else, and the work stalled. The Foundation called the delay "a structural failure, caused by both the security team's decision process and its lack of resources."
Then this summer, several research teams found the same class of bug within weeks of each other, with AI tools as part of their workflow. Calif reported first in August, Wiz independently a couple of weeks later, and OpenAI's Codex Security team in September.
I think that combination is the bigger story. Bugs that have been sitting in widely used open-source code are going to get found faster now, by defenders and by attackers. And the projects that maintain that code are often small teams. When I spoke to Dark Reading on release day, I said the harder part is everything after php.net: the distributions, hosting companies and vendors that ship PHP on to everyone else. The post-mortem shows the strain starts even earlier, inside the project itself. If your business runs on PHP, and most do somewhere, putting money and people behind it is cheaper than the alternative.
What I'd check now
If you've already patched, good. A few things are still worth a look:
- Make sure the fix is actually running. Every PHP worker needs a restart to load it. Updating the package without restarting PHP-FPM or Apache leaves the old code in memory.
- Find your end-of-life PHP. Look past the web servers to appliances, hosting panels and vendor products. For anything on 8.1 or older, get a vendor backport, build the PHP team's backport, upgrade, or take it off the internet.
- Leave
session.upload_progress.enabledset to0. On October 23, PHP published an informational advisory about a related issue, CVE-2026-115560, and recommends keeping it off until the next regular release. Most applications don't use it anyway. - Look for signs of compromise, not just patch status. Watch for unusual
multipart/form-dataPOST requests, requests usingPHP_SESSION_UPLOAD_PROGRESS, bursts of HTTP 500 errors with PHP out-of-memory messages, and unexpected processes started by PHP workers. - Get management interfaces off the internet. Firewalls, VPN gateways, anything with an admin page.
- If you run PHP on Windows, install the rebuilt packages. The 8.x.x-1 Windows builds from October 26 fix a separate Brotli bug, CVE-2026-111497, that can be reached through the cURL extension.
Where Mondoo fits
In Mondoo, PHP findings are scored with our risk dimensions, so an internet-reachable PHP install on a high-value system ranks above the same version on an internal test box. End-of-life PHP shows up as its own finding, separate from any CVE, because it's a risk whether or not this week's advisory names it. If you want to see where PHP is running in your environment, including inside the products you didn't build, that's a good place to start.
Here's what finding and fixing PHP2Shell looks like in Mondoo, from detection through agentic remediation:
Looking ahead
PHP2Shell didn't break the internet. Most supported PHP was patched within days, and that deserves credit. But most of the vulnerable hosts were on PHP that nobody maintains anymore, and that problem was there before October 20 and will still be there next month. That's where I'd spend the time now.
