PHP2Shell, Node2Shell and HTTP2Shell: How SaaS Teams and MSPs Can Find Exposed Servers with Panoptic Scans Written on . Posted in Informational.
On October 21, 2026, three scary names started showing up in security feeds at once: PHP2Shell, Node2Shell and HTTP2Shell. If you run a SaaS product or manage infrastructure for clients, it is easy to assume that means three separate fires. It does not. There are really two bugs behind those three names, and each one calls for a different response. One of them can often be spotted from the outside with an external vulnerability scan. The other mostly cannot, which changes how you should use your scanner.
This post explains what each name refers to, who is affected, why it matters so much for SaaS teams and MSPs, and how Panoptic Scans fits into a practical response, including where its limits are.
Three Names, Two Bugs
Here is the short version before we dig in:
| Name | What it really is | CVE | Can an external scan see it? |
|---|---|---|---|
| PHP2Shell | Two flaws in PHP core | CVE-2026-109618, CVE-2026-109619 | Often, when the server reveals its PHP version |
| Node2Shell | Out-of-bounds write in the Brotli decoder bundled in Node.js | CVE-2026-111497 | Not by version; you can find the exposed apps |
| HTTP2Shell | The same Brotli bug in other HTTP stacks | CVE-2026-111497 (same CVE) | Not by version; you can find the exposed services |
All three were disclosed on October 21, 2026. PHP2Shell and Node2Shell are rated CVSS v4.0 9.2, which puts them firmly in the critical range for anyone exposing these technologies to the internet.
PHP2Shell: Critical Flaws in PHP Itself
PHP2Shell covers two vulnerabilities in PHP core, not in a plugin or framework. That is why it reaches so far.
- CVE-2026-109618 is a memory corruption flaw triggered when PHP runs out of memory in the middle of a request.
- CVE-2026-109619 is a use-after-free, where freed request state carries over to the next request handled by the same worker.
Together they can give an unauthenticated attacker remote code execution, or let them read process memory. Process memory is where the valuable things live: passwords, session tokens and API keys. Both flaws are rated CVSS v4.0 9.2.
Who is affected
Any PHP installation serving web requests should be treated as in scope. That includes mod_php under Apache (the highest risk setup), PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. Wiz reports that every PHP version back to 5.4 is affected by at least one of the two bugs, and it demonstrated remote code execution against current WordPress, Drupal and Joomla images. If you host or manage any of those, this is your problem.
The fix, and the catch
The PHP project released fixes in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older have no official fixed release, so those systems depend on distribution backports. That detail matters later when we talk about scanning, because a backported fix usually does not change the version number a server reports.
Is it being exploited?
CISA issued an alert urging immediate patching. CSA Singapore reports widespread exploitation attempts, and public proofs of concept exist. As of October 23, the bugs were not yet listed in the CISA Known Exploited Vulnerabilities catalog, but that should not be read as a reason to wait. Attempts are already happening.
Node2Shell: A Brotli Bug Inside Node.js
Node2Shell is CVE-2026-111497, an out-of-bounds write in Google's Brotli decoder, versions 1.0.3 to 1.2.0, which is bundled in Node.js. The name was coined by Imperva. Google scores it CVSS v4.0 9.2, while the Node.js project rates it High.
The attack works by sending malicious compressed data. If an application decompresses attacker-controlled Brotli, that data can crash the process, leak memory or run code. There are two common paths:
- Incoming requests: compressed request bodies parsed by Express 5, body-parser 2 or Koa.
- Outgoing requests: responses your app fetches with fetch or axios, which means a malicious server can attack your app when you call it.
Fixes are available in Node.js 22.23.4, 24.22.1 and 26.12.1, Bun 1.4.4, and Brotli 1.0.10, 1.1.1 and 1.2.1. One easily missed point: container images must be rebuilt. Updating Node on your laptop does nothing for the image already running in production. As of October 23, no in-the-wild attacks had been reported.
HTTP2Shell: The Same Bug, Wider Reach
HTTP2Shell is not a separate CVE. As SecureLayer7 explains, it is a looser name for the same Brotli bug when it shows up in HTTP stacks outside Node.js. Despite the name, it has nothing to do with the HTTP/2 protocol.
The affected software list is broader than many teams expect:
- Python Brotli and brotlicffi, which are used automatically by requests, httpx, aiohttp and Scrapy when installed (see Aikido's write-up).
- libbrotli, and curl builds that use it.
- Envoy, fixed in 1.40.0, 1.39.3, 1.38.6 and 1.37.8.
- Istio, fixed in 1.29.9, 1.30.6 and 1.31.2.
It works in both directions: a malicious client can attack a server, and a malicious server can attack a client. That second direction is easy to overlook. Webhook senders, link preview features, crawlers and anything that fetches a URL on a user's behalf are all on the client side of that equation. One piece of good news: Apache and Nginx do not decode Brotli by default.
Why This Matters for SaaS Companies
For a SaaS business, the worst outcomes of these bugs line up with the worst outcomes of a breach. Unauthenticated remote code execution means an attacker does not need an account. Memory disclosure means tokens, API keys and credentials can leak even if the attacker never gets a shell. On shared infrastructure, one leaked key can affect many customers at once.
There is also a compliance angle. If you are working toward or maintaining SOC 2, auditors want evidence that you monitor for vulnerabilities and respond to them. A critical, widely publicized event like this is exactly the kind of thing you want a dated scan report for: proof that you looked, what you found, and that a later scan showed it fixed. Regular continuous vulnerability management turns that from a scramble into routine.
Why This Matters for MSPs
MSPs face the same technical risk multiplied by every client. A typical MSP portfolio includes plenty of WordPress sites, small business portals and older line-of-business apps, and a lot of that runs on PHP that is past end of life. Greenbone cites about 884,000 internet-facing hosts exposing an end-of-life PHP version. Those are exactly the systems that will not get an official PHP fix.
The practical challenge for an MSP is not understanding the bug. It is answering, quickly and for every client, "which of your servers are exposed, and are they fixed yet?" Doing that by hand across dozens of clients does not scale. That is where vulnerability scanning built for MSPs pays off: one place to scan every client, with reports you can put your own name on.
How Panoptic Scans Helps with PHP2Shell
PHP2Shell is the more scanner-friendly of the two bugs, because many PHP servers announce their version in response headers.
Panoptic Scans runs Nuclei vulnerability scans with templates updated before every scan, so you do not need to wait for a product release to pick up new checks. The Nuclei template library includes a PHP2Shell template for CVE-2026-109618. In practice, that means a Panoptic Nuclei scan can flag internet-facing PHP hosts and exposed vulnerable PHP versions across your targets.
From there, the workflow is straightforward. Point Nuclei scans at your public hosts, or at each client's hosts, to find PHP servers advertising affected versions. Patch or apply backports, starting with mod_php setups and anything running PHP 8.1 or older. Then schedule re-scans so you have dated evidence that the finding cleared.
Be clear about the limits, because they are real:
- Hidden versions can be missed. Servers that suppress version headers will not reveal what they run.
- Backports can look vulnerable. Distributions often backport fixes without changing the version number, so a patched server may still report an old version.
- No finding does not mean patched. A clean scan is a good sign, not proof. Confirm patch status on the host itself.
Used with those limits in mind, an external scan is still the fastest way to find the PHP servers you forgot you had, which is often where the real risk sits.
How Panoptic Scans Helps with Node2Shell and HTTP2Shell
The Brotli bug is different. Node.js and Brotli library versions are not visible from outside, so no external scanner can reliably say "this server is vulnerable" by looking at it. Anyone claiming otherwise is overselling.
What Panoptic Scans can do is answer the question that comes first: where are you exposed?
- Inventory. Nmap port scanning and Nuclei help find internet-facing Node.js apps, proxies and Envoy endpoints, including ones that were never on anyone's list. This is the core of external attack surface monitoring.
- Verification. After you patch and redeploy, scheduled re-scans confirm the services you expect are the ones still exposed, and nothing new has appeared.
To confirm the actual library versions, pair Panoptic with dependency or container image scanning, which Panoptic does not provide. That combination covers both halves: Panoptic tells you which services face the internet, and your dependency or image scanner tells you whether the code inside them is fixed. Remember to rebuild images, not just update lockfiles.
Going Beyond the Perimeter
Internet-facing hosts get attacked first, but they are not the only place these bugs live. Internal tools, staging servers and back-office apps often run older PHP and Node versions than production.
Panoptic's OpenVAS network scanning can run internally on the Pro plan, giving you broader visibility of your internal network. For web applications, ZAP web app scanning, including logged-in scans, helps you review the application layer that sits on top of PHP and Node. These are useful for general hygiene around these events, though the PHP2Shell detection described above comes from the Nuclei template.
Automating the Response Across Many Environments
When a critical bug lands, the teams that respond fastest are the ones who already have scans in place. Panoptic Scans supports scheduling, organizations for separating MSP clients, white-label reports and Attack Narrative reports. For larger fleets, the REST API, MCP server and webhooks let you create and run scans across many clients automatically.
For an MSP, that might mean creating a Nuclei scan for every client the morning a disclosure drops, then sending each client a branded report showing what was found and, a week later, what was fixed. For a SaaS team, it might mean asking your AI agent to run a scan on your public hosts and summarize anything critical.
The Bottom Line
PHP2Shell, Node2Shell and HTTP2Shell sound like three crises, but they are two bugs with two different playbooks. PHP2Shell can often be fingerprinted from outside, exploitation attempts are already reported, and many end-of-life PHP servers will never get an official fix, so find your exposed PHP hosts now and re-scan until they are clean. Node2Shell and HTTP2Shell hide inside libraries, so use external scanning to map where you are exposed and dependency or image scanning to confirm the fix.
If you want to see which of your servers, or your clients' servers, are exposed today, check out Panoptic Scans pricing and start scanning. A clear inventory and a dated report are worth a lot more the day before the next 2Shell than the day after.