The zero day you have not met yet
php2shell, PwnEscape, and why compliance status beats a green tick - plus a live session on 12 November with practical building blocks.
On Tuesday 20 October 2026, a video went up on X at 20:27 UTC. It showed a tool that delivered a shell on demand. The advisory it belonged to was not published yet. PHP’s own notice had gone out fifty-five minutes earlier, advising that two critical vulnerabilities in the PHP core would be released the following day.
Before the fixed builds landed, there were public write-ups, exploit bundles and scanners on GitHub, while most administrators were still reading the advisory.
What php2shell actually taught us
The bugs themselves were an out-of-memory bailout path and a use-after-free in the PHP engine. PHP’s supported branches were 8.2 to 8.5. Those got releases. The security team also published minimal source backports for 7.4, 8.0 and 8.1 to help LTS vendors. Nothing was provided for older PHP versions.
We shipped a workaround in the interim, as most vendors did. Disabling session.upload_progress closes one family of the exploit and does nothing for the out-of-memory path, so it held one door shut while we waited for builds. Worth having. Not the same thing as being patched.
The compliance page is the part that answers this
This is why we built the Compliance tool, and why it also runs as an ActiveMonitor check rather than sitting in a report nobody opens.
It inventories every PHP runtime on the server with its version, build and site count, then judges each one against the current advisories:
- Patched: no green checkmark, because that would be a false sense of security. On the day the next zero day is discovered, you don’t want to be looking at a reassuring tick. It is still the best state to be in.
- Patched, update available: amber. You are patched against php2shell, but a newer build of the same branch has been published since. That newer build carries fixes for other items nobody has told you about yet.
- Patched, branch end-of-life: amber. The fix is present and current, but the branch underneath it is dead and may not get future issues patched.
- Upgrade available, upgrade recommended: red. Vulnerable version unpatched, and a fixed build exists. Update and the light clears.
- No patched build, move to a supported branch: red. The branch has no fixed build recorded for your platform, so there is nothing to install. Time to move to a new PHP branch that is patched.
Then the kernel
If php2shell were the only thing that happened this quarter, it would still be worth writing about. It was not.
PwnEscape, CVE-2026-99999. pwn.ai found it while taking Vercel’s sandbox challenge. A well crafted packet from a guest was all it took to leak host memory, crash the host, or run code as root on it. The bug sat in Linux’s IPv4 stack since 2008, in the networking layer rather than the hypervisor, which is why it reached so many environments and why the advisory covers so many trees.
And here is the trap that catches careful people: an installed kernel is not a running kernel. uname -r is the only way to know if you’re safe.
The treadmill
PwnEscape was patched on 20 October. That release carried fixes for sixteen CVEs. Four more kernels have been released on the same branch since.
| When | Fixes | A sample of what came with them |
|---|---|---|
| 26 October | 8 | an xfs bounds check, a vmxnet3 crash on Geneve packets |
| 27 October | 15 | a udp socket address race, a netfilter conntrack leak |
| 3 November | 2 | an ethtool overflow, a bad reply length from an SFP module |
| 5 November | 16 | four sctp use-after-frees, an smc socket use-after-free, a sunrpc TLS race, an openvswitch conntrack teardown |
Forty-one CVEs in the two weeks after PwnEscape. Most of them need a way in first, which is why nobody writes headlines about them. They still count. A chain is built out of small pieces, and this is where the small pieces come from.
How to be prepared
Being ready for the next zero day is not a product you can buy. It is a handful of ordinary things: knowing which PHP branches you carry, how quickly a fix reaches the box, whether an alert would reach a person, and whether the host was rebooted onto its new kernel. None of it is dramatic work, and all of it is cheaper than an incident.
Michael and Greg will share some building blocks you can put in place, starting with the ones that buy the most for the least effort. Bring the server you are worried about and we will tell you where it stands.
The other half of the session
It would be a gloomy conversation if that were all. We have spent a lot of this year on the BlueOnyx out-of-the-box experience, including a new ISO image and the work behind it, and the point of that work is that a fresh install should reach a working, sensible server with less fiddling than it used to take. There is more of it coming.
That is what the session is for: the guidelines, the roadmap and the recent work, and open questions from chat. The compliance tool will tell you which branch your server is on in about ten seconds, and the rest of the conversation is about what to do next.
Live session
Thursday, 12 November 2026 — 15:00–16:00 US Eastern
- New York (US Eastern): 15:00–16:00
- Berlin (CET): 21:00–22:00
- Melbourne (AEDT): Friday 13 November, 07:00–08:00
- Tokyo (JST): Friday 13 November, 05:00–06:00
Bring the server you care about. We will walk the compliance picture, the practical next steps, and the rest of the roadmap in the open chat.