Forecasting the next PHP2Shell

I recently wrote about PHP2Shell and what it should change in the way we run security. The question I’ve been asked most since is the obvious one: what comes next?

Nobody can give you the next CVE number, and I’d be wary of anyone who says they can. What I can do is tell you where I think it will come from. The conditions that turned PHP2Shell into a global event aren’t mysterious, and they apply to a fairly short list of other software. Below I score that list, show my working, and set out what I’d do now so the next one costs you a bad week rather than a bad quarter.

My call   The next event on the scale of PHP2Shell is most likely to come from a compression or media-decoding library that is bundled inside other software. A C-based web server or reverse proxy is a close second, and the DNS forwarder sitting in router firmware is the slow burn behind both. I put the odds at better than even that one of those three gives us a remotely exploitable, KEV-listed bug at internet scale before the end of the first quarter of 2027.   And I also expect it to reach us the way PHP2Shell did, through a broken embargo rather than as a true zero-day. There are now thousands of serious, undisclosed bugs sitting in disclosure queues, and the people holding them are not the only ones capable of finding them.  This is a judgement rather than a measurement. I've shown how I reached my conclusion so you can review it and challenge anything you disagree with.

 

1. Why this can be forecast at all

For most of my career, predicting the next big vulnerability was guesswork. Heartbleed and Log4Shell turned up because somebody happened to look in the right place, and years went by between them. Three things have changed this year, and between them they’ve turned it into something closer to weather forecasting. You still can’t name the day, but you can say with some confidence where the storm will form. 

The first is that the people finding bugs are now organised, well funded and open about what they’re looking at. OpenAI’s Patch the Planet programme has published its first list: cURL, NATS, pyca/cryptography, Sigstore, aiohttp, Go, freenginx, Python and python.org, with Trail of Bits working across nineteen projects and more rounds promised. Anthropic’s Project Glasswing has well over a hundred partner organisations pointing its Mythos model at operating systems, browsers and critical infrastructure. Palo Alto’s NOVA pipeline scanned 3,915 open-source projects in two months. If you want to know which software will be producing advisories next quarter, those lists are a good place to start. 

The second is volume. Google counted 10,740 new CVEs in August, against 5,045 in January. NOVA alone produced 14,090 confirmed findings, and only 85 of them matched anything already public. One independent researcher’s reading of Glasswing is that its early partners had found more than 10,000 high-severity bugs by September and fixed fewer than one in a hundred. Argue with the exact figures if you like. The point stands there’s now a queue, and a queue of undisclosed critical bugs is a queue of future Black Octobers. 

The third is that the bugs AI finds are the ones attackers want. Google’s data shows half of AI-found flaws lead to remote code execution, against about a quarter of everything else. Exploitation is rising with them: 141 vulnerabilities exploited in the wild in the first eight months of this year, more than the 127 for the whole of 2025, with zero-days running at about eleven a month. The BeyondTrust flaw an AI agent found in February was being exploited four days after it was disclosed. 

So I no longer think the useful question is whether there will be another one. The more useful question is which of a known set of candidates goes first. 

2. What the last twelve years tell us

I’ve been in this industry long enough to have watched every entry in this table land. when you line them up the similarities are hard to miss. 

The same five things keep coming up, and they’re what I score against in the next section. 

• Ubiquity. It’s in most of the internet by default rather than by choice. Nobody decided to run PHP; it came with WordPress. 
• Unsafe code with a long history. All but one of the entries above is written in C, and several of the bugs were more than ten years old when they were found. 
• Unauthenticated reach. The first piece of code to touch untrusted bytes from the internet is the piece that gets exploited. 
• Patch sprawl. One upstream fix turns into dozens of vendor advisories on dozens of timelines, or into an end-of-life estate that never gets a fixed binary. libwebp and the copy of Brotli inside Node.js are the textbook examples, and PHP 7.4 still running on 16% of hosts is what that looks like in practice. 
• AI focus. This one’s new, and it moves fastest. If a project is on a published audit list, advisories are coming, whether or not an attacker is also looking. 

3. The watchlist, scored 

I’ve scored each candidate from one to five on those five factors. It’s deliberately simple, so you can see the argument rather than a black box. Section 4 has the reasoning, and that’s where I expect to be challenged. 

One rule overrides the totals. If a candidate scores two or less on either unauthenticated reach or patch sprawl, I don’t think it can become a slow, global event, however high it scores elsewhere. A bug nobody can reach remotely, or one that nearly everyone patches automatically within days, stays a serious but contained problem. That rule is why the browsers and the kernel sit lower than their totals suggest. Edge appliances are a separate case: they’re hit constantly, but each bug lands on one vendor’s customers at a time. 

4. The reasoning, candidate by candidate 

1.  Bundled compression and media decoders 

zlib, Brotli, zstd, libarchive, libpng, libjpeg-turbo, libwebp, ffmpeg   ·   Most likely, 24/25 

This is my first pick, and Node2Shell is the reason. Last week’s Node.js release fixed an out-of-bounds write in the copy of Brotli that ships inside the runtime, and a lab exploit against an unpatched build was reported the following day. libwebp in 2023 was the same story. These libraries sit exactly where untrusted bytes are first unpacked, they are written in C, and they get copied into thousands of products instead of being installed once. One bug becomes a hundred vendor advisories on a hundred timelines, and the long tail never gets patched at all. 

2. HTTP servers and reverse proxies 

NGINX, freenginx, Apache httpd, HAProxy, Envoy, IIS, Pingora   ·   Most likely, 22/25 

freenginx is on the Patch the Planet list, and that programme has already pulled a denial-of-service bug, which it calls HTTP/2 Bomb, out of NGINX, Apache, IIS and Pingora at the same time, with more than 880,000 sites exposed. HTTP/2 and HTTP/3 are young, complicated protocols implemented largely in C, and they sit in front of everything. Several well-funded teams will now be looking for the remote code execution version of that bug. I’d assume one of them finds it. 

3. DNS forwarders in firmware 

dnsmasq, BIND, Unbound, embedded forwarders   ·   Most likely, 22/25 

Four of six recent dnsmasq CVEs are credited to the Patch the Planet work. dnsmasq is in most home routers, a good deal of enterprise kit and plenty of container tooling, and router firmware is the estate nobody patches. If this one goes, I wouldn’t expect a 48-hour scramble. I’d expect a decade of exploitable boxes sitting in branch offices and people’s homes. 

4. Interpreters and language runtimes 

CPython, Ruby, Perl, the JVM, the Go runtime   ·   Likely, 20/25 

PHP was the first interpreter to fall, and I don’t think it will be the last. Python is on the Patch the Planet list and underpins most of the AI stack. Runtime bugs usually need an application path to reach them, which is why I have marked reach down. End-of-life Python and Ruby are still everywhere, though, runtimes get copied into appliances and container images, and the AI tooling is pointed straight at this layer. 

5. TLS libraries and the certificate trust layer 

OpenSSL, GnuTLS, wolfSSL, certificate authorities   ·   Likely, 20/25 

This is where Heartbleed lived. OpenSSL has been audited hard for twelve years, and that is the main thing holding the score down. The trust layer above it has not had the same attention. eMudhra announced last week that it is leaving the global TLS certificate business, days after it emerged that keys from a 2025 key ceremony were recoverable. A weak-key or certificate-validation bug that lets an attacker mint trusted certificates is the one global event on this list that needs no patch on your side, because nothing on your side is broken. 

6. AI inference and orchestration 

vLLM, Ollama, LiteLLM, Langflow, Flowise, MCP servers   ·   Likely, 20/25 

Google counts 212 disclosures in inference and serving software this year, nearly a quarter of them unauthenticated endpoints or server-side request forgery. Last week a compromised LiteLLM release sat on PyPI and Docker Hub for around two hours carrying a credential stealer. The footprint is a fraction of PHP’s, which is why it only scores three for ubiquity. But it’s growing quickly, it sits next to every API key an organisation owns, and much of the code was written in a hurry by people optimising for speed. This is the row I expect to move up first. 

7. Browser engines 

V8, JavaScriptCore, SpiderMonkey   ·   Frequent, contained, 21/25 

The Patch the Planet write-up cites five exploitable bugs in Chrome’s V8 and more than ten in Safari, found in about a week. Browsers get hit constantly. They also update themselves within days, which keeps the global window short and is why the override applies. The exposure that worries me is the corporate fleet where someone has switched automatic updates off. 

8. Linux kernel, remotely reachable 

Network stack, filesystems, eBPF   ·   Possible, 20/25 

Copy Fail showed this spring that a nine-year-old local bug can be weaponised and on the KEV list within a week of disclosure, and the Patch the Planet kernel work reports 24 privilege-escalation proofs of concept. What keeps the kernel out of the top bands is reach, because remotely triggerable kernel bugs are rare. As the second stage behind any of the other candidates, though, I’d treat it as close to certain. 

9. Edge security appliances 

VPN gateways, NetScaler, PAN-OS, Ivanti, Fortinet   ·   Certain, not global, 19/25 

This is the most exploited class of all. NetScaler had zero-days in September and attackers were still working a PAN-OS bug in October. New ones will land on the KEV list every month. I’ve only kept them out of the global frame because each bug hits one vendor’s customers rather than the whole internet. If you are deciding what will actually hurt you in the next ninety days, start here. 

5. Why the next one will probably leak

PHP2Shell was not a zero-day in the usual sense. It was a responsibly reported bug whose embargo failed three different ways in 48 hours. I think the next one will look the same, for a simple reason. Coordinated disclosure was designed for a world where a handful of researchers held a handful of secrets. Today the number of organisations holding serious undisclosed bugs runs into the thousands. 

Look at the numbers. Glasswing has well over a hundred partners. Patch the Planet has nineteen projects in its first round and a triage pipeline through HackerOne. NOVA matched only 85 of its 14,090 findings to anything public. Every one of those findings is a secret shared between a maintainer, a researcher, a vendor and whichever cloud providers were briefed early. Secrets shared that widely don’t stay secret for ninety days. 

Rediscovery makes it worse. Calif and Wiz found PHP2Shell independently. One headline Mythos bug was found again by all eight open-weight models in an independent test, including one with only 3.6 billion active parameters. If a small, free model can find it, so can anyone. 

In practice, “we haven’t heard anything” is no longer evidence of safety for anything on this watchlist. A leak can come from a forum post, a video released by mistake, or a vendor shipping a patched build a day early so that anyone can compare it with the old one. My working assumption now is that the gap between the first public hint and a working exploit is under 24 hours, and the gap between a working exploit and mass scanning is minutes. 

6. Six early warnings

None of these is a CVE, but last time every one of them showed up before the CVE did. 

 

 

7. Preparing for a class of bug, not a CVE

The Army taught me that time spent on reconnaissance is seldom wasted, and that holds here too. A forecast is only worth anything if it changes what you do before the event, and the steps below pay off whichever candidate goes first. Most of them are cheap; the main cost is somebody making a decision.

 

8. Where I might be wrong 

I have ranked by the likelihood of a remote, internet-scale event. If you rank instead by what is most likely to hit your organisation in the next ninety days, edge appliances win easily. Both rankings are valid; they’re just answering different questions. 

I may be underweighting the trust layer. A certificate-authority failure or a validation bug in a TLS library is the one scenario here with no patch to apply, because what is broken is trust, not code. eMudhra was contained because no end-entity certificates had been issued from the affected keys. Next time we may not be so lucky. 

I may also be early on the AI stack. Its footprint is a fraction of PHP’s, which is why it scores three for ubiquity. But it is growing fast, and the first exploited AI-infrastructure bugs, in LiteLLM and Langflow, have already arrived. If the next twelve months go like the last, that row moves up a band. 

Finally, none of this scoring accounts for intent. Everything above assumes bugs found by researchers and leaked by accident. A state actor sitting on a decoder or interpreter bug it found with its own models would not show up in any of the signals in section 6 until it chose to use it. 

Speak to our cyber experts

This is the second of two papers. The first, “The patch was the easy part”, covers PHP2Shell itself. 

 

Sources 

All accessed 27 October 2026. 

1. OpenAI, “Patch the Planet: a Daybreak initiative to support open source maintainers”.  https://openai.com/index/patch-the-planet/
2. Trail of Bits, Patch the Planet programme page. www.trailofbits.com/patch-the-planet 
3. Unit 42, “The Frontier AI Vulnerability Burst: Industrializing Autonomous Zero-Day Discovery in Open-Source Software”, August 2026. https//unit42.paloaltonetworks.com 
4. Help Net Security, “The vulnerabilities AI finds are the ones attackers want” (Google Threat Intelligence Group data), 1 October 2026. https://www.helpnetsecurity.com/
5. Wikipedia, “Black October (information security)” and “Claude Mythos”, accessed 27 October 2026 
6. Anthropic, “Expanding Project Glasswing”, June 2026. https://www.anthropic.com/news/expanding-project-glasswing
7. R. Kováč, “Lessons from Cybersecurity Black Week”, ESET WeLiveSecurity, 28 October 2026. https://www.welivesecurity.com/en/business-security/lessons-cybersecurity-black-week/
8. Aikido Security, “Node2Shell: CVE-2026-111497 Node.js Brotli RCE”. aikido.dev 
9. Help Net Security and Qualys on Copy Fail, CVE-2026-31431, April–May 2026. 
10. Unit 42 threat briefs on NetScaler zero-days (September 2026) and PAN-OS CVE-2026-0257 (October 2026). 
11. Amazon Threat Intelligence, PHP2Shell exploitation prior to public disclosure in MadPot, 21 October 2026. https://aws.amazon.com/blogs/security/
12. H. Hughes, “The patch was the easy part”, LRQA Cyber, 27 October 2026. 

The scoring in section 3 is my judgement, built on the published evidence listed above. It is not a measurement, and reasonable people will weight the factors differently. Third-party figures are as published and will move. The Glasswing disclosure and fix rates come from independent commentary, not from Anthropic. None of this replaces an assessment of your own estate.