PHP2Shell, Node2Shell, HTTP2Shell: what needs fixing?

PHP2Shell: a request can fail before your application handles it

The PHP team’s 21 October advisory identifies CVE-2026-109618 and CVE-2026-109619. They concern memory corruption during request handling, rather than a missing input check in a WordPress plugin or Laravel controller. PHP names web-serving installations including PHP-FPM and Apache mod_php as at risk.

For the out-of-memory flaw, an allocation failure can interrupt initialization. Cleanup later encounters internal data that was never fully prepared. The stale-state flaw leaves references to request memory after that memory has been freed. Later work in the same worker can encounter those invalid references.

That distinction affects where a defence must act. PHP reports a demonstrated mod_php exploit reachable before application code runs. Adding validation inside the application cannot protect a path that executes before the application gets control.

Updating is the complete remedy for the disclosed pair. PHP also published a separate session-upload-progress advisory on 23 October, CVE-2026-115560, involving an unusual configuration and a runtime change of session serialization handler. Read that follow-up as well; fixing the original pair does not settle every later session-related advisory.

Node2Shell and HTTP2Shell: follow the compressed bytes

Brotli makes data smaller for transfer or storage. A decoder reconstructs it. The October Node.js advisory describes a decoder error that treats invalid input as a request for more input. Continuing from that state can write beyond an internal buffer and corrupt process memory.

The important condition is attacker-controlled Brotli data reaching an affected decoder. Having Node.js installed is not enough to demonstrate that path. An application might decode an incoming compressed request through middleware, or consume a compressed response from a remote server.

HTTP2Shell is a wider nickname for this same decoder bug, not a diagnosis of a flaw in HTTP/2 itself. Switching an application to HTTP/1.1 does not replace its Brotli decoder. The affected component, rather than the protocol version in the name, determines what needs updating.

The Python advisory covers the Brotli and brotlicffi packages. Bun’s advisory identifies its bundled Brotli copy and APIs that decode untrusted data. This is why a search limited to Node.js services can miss other copies of the same vulnerable dependency.

Imperva reports reproducing code execution in its Node.js test environment and rejection of the same input after patching. That is stronger evidence than a crash alone, but it is still a report about a particular setup. We have not repeated that experiment.

React2Shell shows why a common suffix is not a common cause

React2Shell is the name used for CVE-2025-55182, disclosed in December 2025. It concerns React Server Components, not PHP cleanup or Brotli memory handling.

React’s advisory describes a flaw in decoding requests sent to Server Function endpoints. Applications supporting React Server Components could be exposed without explicitly implementing Server Functions. Conversely, a React application with no server was outside this vulnerability’s scope.

I prefer separate remediation records for these issues. A PHP runtime update cannot fix an affected React server package. Updating a React framework does not, by itself, replace a vulnerable Brotli copy embedded in a different process.

Patch references, checked 25 October 2026

The releases below contain fixes for the named October vulnerabilities. They are a dated reference, not a promise that these versions resolve every security issue. Prefer the current security-fixed release supported by your vendor. For distribution packages, check the vendor advisory and package revision because fixes may be backported.

PHP, for CVE-2026-109618 and CVE-2026-109619: 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The separate 23 October advisory has its own guidance.

Node.js, for CVE-2026-111497: 22.23.4, 24.22.1 and 26.12.1. These are runtime releases. Changing an application’s npm dependencies alone does not necessarily replace its Node.js binary.

Native Brotli: fixed branch releases are 1.0.10, 1.1.1 and 1.2.1. For the Python packages, the advisory lists Brotli 1.2.1 and brotlicffi 1.2.1.0. Library and language-binding versions are different inventories.

Bun: 1.4.4 contains the decoder fix. Its advisory also requires rebuilding executables produced with an affected Bun runtime. Updating the Bun installation used for future builds does not repair binaries already distributed.

A worked example: the website is not the only consumer

Consider a fictional product with a PHP website and a separate Bun worker that fetches user-supplied URLs to generate previews. The hosting provider updates PHP. The team also updates Bun on a developer laptop. The deployed preview worker is still an executable built with an older runtime.

Bun’s advisory explains that fetch can automatically decode a response marked Content-Encoding: br. In this example, a server the worker visits can supply bytes to the decoder. Blocking Brotli request bodies at the website’s front door would not cover that outgoing-response path.

I recommend mapping each deployed process to the component it actually loads, then rebuilding the affected worker with a fixed runtime. Confirm the replacement artifact is running and test ordinary preview requests as well as failure handling. The verification target is the deployed executable, rather than a successful upgrade on the laptop.

Bun documents a per-request option to disable fetch decompression, but says there is no process-wide workaround. I would treat a temporary control as a path-specific measure whose coverage needs checking, not as permission to defer replacing affected runtimes.

What I would ask for before closing the incident

I recommend an inventory that includes the runtime inside each deployed image and any bundled executable. Record which service owner installed the fixed package, which artifact replaced the old one, and how you confirmed that running processes use it. For managed hosting, ask the provider to identify the remediation that applies to your service.

I prefer to keep patch verification separate from compromise investigation. A successful update establishes a new software state. It does not establish what happened before the update. If there are signs of compromise, preserve the relevant evidence and follow the incident-response process rather than treating a clean version string as an all-clear.

I think the nicknames are useful for getting attention. The work underneath them is more specific: identify the affected component, trace the input that reaches it, and verify the replacement in production. Node2Shell becoming HTTP2Shell is a useful reminder that a dependency can cross the language boundaries of your inventory.