PHP2Shell and HTTP2Shell: What October 2026’s Critical Vulnerabilities Reveal About Legacy Systems

Reading time: 11 minutes. Facts checked against vendor advisories and security research published 21–23 October 2026.

Key takeaways

• PHP2Shell is the nickname for two critical remote code execution flaws in the PHP engine itself — CVE-2026-109618 and CVE-2026-109619. Both score 9.2 (Critical) on CVSS v4.0. The PHP team pushed fixes on 21 October 2026 in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• HTTP2Shell — first called "Node2Shell" — is CVE-2026-111497, an out-of-bounds write in Google's Brotli decompression library spanning versions 1.0.3 to 1.2.0. It's fixed in Brotli 1.0.10, 1.1.1 and 1.2.1, and in Node.js 22.23.4, 24.22.1 and 26.12.1. The name is misleading: it has nothing to do with the HTTP/2 protocol.
• Both bugs sat unnoticed in foundational code for years. Heavy use of AI-assisted code analysis is what finally surfaced them.
• Systems under active support could be patched within hours. End-of-life systems could not. PHP 8.1 and older received no official release — only source-level backports for 7.4, 8.0 and 8.1, and nothing whatsoever for 5.4 through 7.3.
• The real lesson isn't about a single patch cycle. It's that legacy software turns every critical CVE into a project instead of an update — and legacy system modernization is the only fix that lasts.

What happened in October 2026

Two unrelated vulnerabilities hit the runtimes that power a huge share of the web, and they landed within roughly 48 hours of each other. Researchers lumped them together almost immediately. Some commentators are now calling that week "Black October."

Coincidental timing. Not a coincidental pattern. Both were memory-safety bugs buried in low-level C code that nearly every application depends on — and almost no application team ever reads.

What is PHP2Shell?

PHP2Shell is a pair of critical memory-safety vulnerabilities in the PHP interpreter that let an unauthenticated attacker execute code on a web server by sending a crafted HTTP request. The security community came up with the name. The PHP project did not.

The two CVEs behave differently:

• CVE-2026-109618 — RCE via out-of-memory corruption. When PHP runs out of memory at just the wrong moment, request processing can be interrupted while internal request data is only partly set up. The cleanup routine then treats that half-built data as valid. An attacker can turn that into code execution.
• CVE-2026-109619 — RCE via stale global state. Request-scoped internal state can outlive the memory backing it — a classic use-after-free. The most widely discussed path runs through PHP's session upload progress feature, which is enabled by default.

Researchers at Calif, Wiz and OpenAI are credited with the finds, according to advisory coverage. The flaws affect every PHP server API that handles web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Wiz demonstrated pre-authentication RCE against unmodified official container images of WordPress, Drupal and Joomla. Not because those CMSs were at fault — because the vulnerable code runs inside the PHP engine beneath them.

Business owners should keep two things in mind:

1. Updating WordPress, Laravel, Drupal or any plugin does not fix PHP2Shell. The runtime itself has to be patched.
2. No configuration change fully closes the hole. The PHP team published interim settings (disabling session.upload_progress.enabled, or adjusting memory_limit, for instance), but each blocks only one known path. The official patch is the only complete fix.

Several analyses note that the underlying memory-handling weaknesses date back to the PHP 5 era. The bug has been shipping in production for well over a decade.

What is HTTP2Shell?

HTTP2Shell (CVE-2026-111497) is an out-of-bounds write in the decoder of Google's Brotli compression library that allows a remote attacker to corrupt memory by sending a crafted Brotli-compressed stream. The official CVE record classifies it as CWE-787. Possible outcomes range from denial of service and memory disclosure to arbitrary code execution.

It was called Node2Shell at first, because Node.js shipped the first fix. The rename came once researchers realized the vulnerable code lived in the shared C library, not in Node.js. Brotli is everywhere. It compresses web traffic (Content-Encoding: br) and is bundled into Node.js, Bun, Python packages such as brotli, brotlicffi, aiohttp and httpx, Java's brotli4j, Go's cbrotli, curl, Envoy and Istio, among others.

The risk concentrates in services that automatically decompress untrusted Brotli input — API gateways, proxies, webhook receivers and upload endpoints. At publication, CISA's assessment recorded no known exploitation. Defenders got a short head start that PHP2Shell — with public proof-of-concept code circulating within days — did not.

Have PHP2Shell and HTTP2Shell been patched?

Yes. Official fixes exist for both. But a fix existing is not the same as your systems being fixed.

One practical trap: many Linux distributions and control panels backported the PHP fix without changing the visible version number. Ubuntu, RHEL, cPanel and Plesk all shipped fixed builds whose php -v output looks identical to the vulnerable one. The fix lives in the package revision or build date. Checking the version string alone can give you a false sense of safety.

Why legacy systems are hit hardest

For a team running PHP 8.4 on a maintained stack with automated builds, PHP2Shell was a stressful afternoon. For a team running a ten-year-old PHP 7 application on a server nobody wants to touch, it was a crisis. Industry figures quoted after disclosure put the scale in perspective: of roughly 2.2 million internet-facing hosts advertising PHP, close to 900,000 run end-of-life versions that will never receive a normal fix.

Five recurring reasons explain why legacy environments struggled.

1. End-of-life runtimes don't get patches

The PHP project stopped supporting 8.1 and older before this disclosure. Its emergency source backports were an exception, and they only help teams able to compile PHP from source. Anyone on PHP 5.x or 7.0–7.3 has no upstream patch at all. The options: isolate the system, pay for a third-party long-term-support vendor, or upgrade.

2. Upgrading is a compatibility project, not a click

Moving a legacy application from PHP 7.4 to 8.x means dealing with removed functions, stricter typing, changed error behavior and abandoned frameworks or extensions. A setting changed in a hosting panel can break checkout, invoicing or a customer portal. That's why so many companies stay on old versions — and why a critical CVE suddenly forces a decision they've postponed for years.

3. Hidden and bundled copies

HTTP2Shell is a textbook case of dependency sprawl. Most teams never chose Brotli; it arrived inside a runtime, a language package, a reverse proxy or a base container image. PHP is similarly embedded in appliances, control panels and vendor software. You can't patch what you don't know you run. And legacy estates rarely have an accurate software bill of materials (SBOM).

4. Frozen builds and "pets" instead of "cattle"

Node.js fixed HTTP2Shell quickly. Containers built last month still carry the vulnerable library until someone rebuilds and redeploys them. Hand-configured legacy servers are worse. No reproducible build. No automated test suite. Often no one who remembers how the server was set up.

5. Knowledge has left the building

The original developers of many legacy systems have moved on. Without documentation or tests, even a small runtime update carries real risk. So updates get delayed. Delayed updates are exactly what attackers count on.

The AI factor: why this will keep happening

Both vulnerabilities were surfaced with significant help from AI-assisted code analysis. Once the PHP identifiers leaked, researchers described large numbers of language models being pointed at the PHP source within hours. Working exploits appeared within days.

This changes the economics of legacy risk. Old C code that survived years of human review is now being re-read at machine speed — by defenders and attackers alike. AI can also diff a patch and help reconstruct an exploit far faster than before. The window between disclosure and mass exploitation is shrinking. The time it takes to patch a legacy system has not changed. Every month an organization stays on an unsupported runtime, that gap gets wider.

Patch, isolate or modernize? A decision framework

Not every legacy system needs a rewrite tomorrow. After PHP2Shell and HTTP2Shell, each affected system falls into one of four positions:

The last row is where most of the business risk sits. Isolation and firewall rules buy time. They are not a security strategy. Security agencies and vendors issued the same advice after PHP2Shell: isolate end-of-life servers now, and plan the upgrade to a supported version.

Security debt is technical debt

It's tempting to treat October 2026 as a security incident that IT has now handled. A more useful view: PHP2Shell and HTTP2Shell exposed technical debt that was already on the balance sheet.

A legacy system carries hidden costs that rarely show up in budgets:

• Emergency response cost. Every critical CVE triggers unplanned work, overtime and sometimes paid LTS contracts.
• Opportunity cost. Teams that spend their time keeping old systems alive aren't building new features.
• Compliance exposure. Frameworks such as ISO 27001, PCI DSS, and the EU's NIS2 and Cyber Resilience Act expect organizations to run supported software and patch known vulnerabilities promptly. "We couldn't upgrade" is an increasingly weak position in an audit — or after a breach.
• Hiring and knowledge risk. Fewer developers want to work on obsolete stacks. That makes each update more expensive.

Viewed this way, legacy system modernization is not an IT vanity project; it is risk reduction with a measurable return. The question is no longer whether to modernize. It's how to do it without disrupting the business.

How to modernize a legacy application without a big-bang rewrite

The most common modernization failure is the all-at-once rewrite that runs over budget and never ships. A safer approach is incremental and evidence-driven.

Step 1: Inventory and assess

Build an accurate map of every application, runtime version, framework, library and bundled component — ideally as a machine-readable SBOM. Rank each system by business criticality, internet exposure and support status. After October 2026, the first filter is simple: anything on PHP 8.1 or older, or shipping Brotli 1.2.0 or earlier, goes to the top of the list.

Step 2: Choose the right strategy per system

Modernization is not one technique. The industry commonly uses the "7 Rs":

• Rehost — move as-is to new infrastructure (useful, but doesn't fix an EOL runtime).
• Replatform — upgrade the runtime and hosting with minimal code change, for example PHP 7.4 to 8.4 in containers.
• Refactor — restructure code to remove deprecated features and improve maintainability.
• Rearchitect — split a monolith into services or modules where it brings real benefit.
• Rebuild — rewrite critical components on a modern stack.
• Replace — switch to a commercial or SaaS product.
• Retire — decommission systems that no longer earn their keep.

Most real projects combine several of these across a portfolio.

Step 3: Add a safety net before touching code

Write characterization tests that capture what the system does today. Set up a reproducible build and CI pipeline. This is what turns the next critical CVE from a crisis into a routine redeploy.

Step 4: Migrate incrementally

Use the strangler fig pattern: route traffic through a façade, move one feature or module at a time to the modern implementation, and retire the old code as you go. The business keeps running throughout. Each step can be rolled back.

Step 5: Build continuous maintenance into the result

Modernization is not a one-time event. Automated dependency scanning, scheduled runtime upgrades well before end-of-life dates, and container rebuilds on every base-image update keep the new system from becoming the next legacy system.

A 30-day action plan after PHP2Shell and HTTP2Shell

1. Days 1–3: Patch every supported PHP, Node.js, Bun and Python environment. Verify fixes by package revision, not just version number. Rebuild and redeploy container images.
2. Days 3–7: Inventory every PHP and Brotli copy, including those inside appliances, control panels and vendor products. Isolate any end-of-life PHP from the public internet.
3. Days 7–14: Review logs for unusual child processes spawned by PHP workers — a common indicator of PHP2Shell exploitation. Where Brotli request bodies aren't needed, strip or block inbound Content-Encoding: br at the proxy.
4. Days 14–30: Produce a modernization roadmap for every system that couldn't be patched cleanly, with owners, budget and target dates. PHP 8.2 itself reaches end of life on 31 December 2026, so systems on 8.2 belong on that list too.

How Avori helps with legacy system modernization

If PHP2Shell or HTTP2Shell left you with servers you couldn't patch, applications you're afraid to upgrade, or an inventory you're not sure is complete — that's exactly the situation a structured modernization program is designed for.

Avori's legacy system modernization services help companies assess outdated applications, choose the right strategy for each system, and move them to supported, maintainable technology step by step, without stopping the business. Whether you need an urgent upgrade of an end-of-life PHP application or a longer-term roadmap for your whole software portfolio, the goal is the same: the next critical vulnerability should be a routine update, not an emergency.

Talk to Avori about modernizing your legacy systems →

Frequently asked questions

What is PHP2Shell?

PHP2Shell is the nickname for CVE-2026-109618 and CVE-2026-109619, two critical memory-safety vulnerabilities in the core PHP interpreter disclosed and patched on 21 October 2026. They allow unauthenticated remote code execution through crafted web requests and are rated 9.2 on CVSS v4.0.

What is HTTP2Shell, and is it related to HTTP/2?

HTTP2Shell is CVE-2026-111497, an out-of-bounds write in Google's Brotli decompression library affecting versions 1.0.3 to 1.2.0. It is not related to the HTTP/2 protocol. It was first called Node2Shell because Node.js shipped the first fix.

Which PHP versions fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 7.4, 8.0 and 8.1 received source-only backports, and PHP 5.4 through 7.3 have no upstream fix.

Does updating WordPress or my CMS protect me from PHP2Shell?

No. The vulnerability is in the PHP runtime, not in WordPress, Drupal, Laravel or any plugin. You must update the PHP package on the server or container.

Which Node.js versions fix HTTP2Shell?

Node.js 22.23.4, 24.22.1 and 26.12.1. Applications that use Brotli through other languages need Brotli 1.0.10, 1.1.1 or 1.2.1, or an updated package that bundles it.

What should I do if my application runs on an end-of-life PHP version?

Isolate it from the internet, add web application firewall rules and monitoring, apply a vendor or LTS backport if one exists, and start planning an upgrade or migration to a supported version as a priority.

Why does legacy software make vulnerabilities more dangerous?

Because unsupported runtimes don't receive patches, upgrades often require code changes, bundled dependencies are hard to find, and missing tests and documentation make every change risky. Legacy system modernization removes those obstacles so security updates can be applied quickly.

Sources:

• PHP ships emergency patches for critical PHP2Shell flaws — BleepingComputer
• PHP2Shell Vulnerabilities: CVE-2026-109618 and CVE-2026-109619 — VulnCheck
• PHP2Shell: Responding to CVE-2026-109618 and CVE-2026-109619 — Tanium
• CISA advises orgs to patch PHP2Shell bugs immediately — SC World
• Stopping PHP2Shell — SentinelOne
• PHP2Shell fixes by distro, control panel and PHP version — Digital Applied
• Google Brotli v1.2.1 release notes — GitHub
• CVE-2026-111497 record — CVE Project
• Node.js v24.22.1 release notes — GitHub