Express 5 and Node2Shell: Stopgaps Until You Patch

Express 5 can send a Brotli-compressed request body straight into the vulnerable Node.js decoder. CVE-2026-111497 can corrupt process memory when an application decompresses attacker-controlled data; Node.js fixed it on 21 October 2026 in 22.23.4, 24.22.1 and 26.12.1.⁠¹ If you cannot upgrade the runtime today, disable request-body inflation or reject Brotli requests at the edge, and keep the outbound HTTP path on your patch list.

The complete PHP2Shell and Node2Shell guide covers the shared Brotli flaw. This page stays with the temporary controls available to an Express operator.

Express 5's parsers can expose the decoder before login

Express's own migration guide says its JSON, URL-encoded, text and raw body parsers gained support for incoming Content-Encoding: br bodies in version 5.⁠³ The body-parser 2.2.0 documentation confirms Brotli support for the same four parser types and says decompression is enabled by default.⁠⁴ With the relevant parser mounted, a matching request's compressed body reaches Node.js's bundled Brotli decoder. A bare node:http server does not decompress request bodies just because they arrived.

Reported Imperva tested the official Node.js 24.22.0 Linux arm64 image with Express 5.0.0 and 5.3.0, and pinned body-parser 2.x configurations. Its researchers demonstrated code execution through configured JSON and raw parsers; the same inputs did not execute code on patched Node.js 24.22.1. They did not test every intermediate Express release or every architecture.⁠⁵ Express and body-parser are routes into the flawed runtime, not the packages carrying the defect.

Datadog reports that Express 4's built-in parsing path returns HTTP 415 for Brotli request bodies.⁠⁶ That is a narrower finding than saying Express 4 is safe. An Express 4 application can still explicitly decompress Brotli or fetch a compressed response. Koa and NestJS deployments also need a parser-by-parser check: the framework name does not prove which middleware processes incoming bytes.

How you'd notice

Start with the Node.js binary running in production, not the version in package.json or a container tag. Check its actual node -v output, then your installed Express and body-parser versions. Find where express.json(), express.raw(), express.text() and express.urlencoded() are mounted. If the parser runs before authentication, an unauthenticated caller can reach that code path when its content type matches.

Look for Content-Encoding: br on inbound requests in reverse-proxy or access logs, provided you actually record that header. It identifies Brotli traffic, not an exploit. Correlate it with parser errors, unusual worker restarts, CPU spikes and the routes that received the requests. Datadog found that memory corruption did not necessarily produce an application exception; its test sometimes returned HTTP 200 and kept responding to health checks.⁠⁶

A quiet access log is not an all-clear.

There is also a version trap. Datadog found that patched Node.js 24.22.1 could still report Brotli 1.2.0 through process.versions.brotli, because the fix was backported without a library-version bump.⁠⁶ For a vendor-packaged Node.js build, check the vendor advisory; a headline version number may not tell you whether its patch was backported.

Inflate false rejects compressed bodies, not just Brotli

The immediate application-level option is inflate: false on each Express 5 or body-parser 2.x parser handling untrusted request bodies. Express's body-parser documentation says that the default is true; with false, a compressed body is rejected rather than passed through untouched. The documented result is HTTP 415 with error type encoding.unsupported.⁠⁷ This behavior is documented for the JSON, raw, text and URL-encoded parsers. Check every mounted parser, including route-specific ones, before considering the stopgap deployed.

There is a cost. inflate: false rejects gzip and deflate request bodies as well as Brotli, and therefore can break legitimate integrations. If your clients use other compressed request formats, a reverse-proxy rule that rejects inbound Content-Encoding: br is more selective. Confirm that the proxy enforces it on every public path to the Node service and that requests cannot bypass the proxy. Test with a legitimate compressed client, not with exploit data.

Neither measure repairs Node.js. The proxy can act before a request reaches the parser; the parser option prevents that parser from decompressing the body. Other middleware, explicit node:zlib calls and traffic arriving by another route are separate exposure paths. Treat the change as a temporary boundary, with an owner and a removal condition, rather than a vulnerability ticket you can close.

Outbound fetch remains a separate way in

Node.js's built-in fetch() automatically decompresses a response labeled Content-Encoding: br. Datadog reports that it does so even when the request sets Accept-Encoding: identity, and that axios, got and node-fetch also advertise and decode Brotli by default in the configurations it examined.⁠⁶ A webhook tester, link preview service or feed reader can be exposed when it retrieves a URL whose server controls the returned body. Disabling Express request-body inflation changes none of this.

Imperva demonstrated its result over both the inbound parser and outbound fetch() paths on the tested Node.js build.⁠⁵ This is why changing a WAF rule cannot close the issue. Vercel says it installed inbound WAF rules on 21 October, but explicitly warns that those rules do not cover responses fetched by its applications. It separately introduced managed-runtime protections for some outbound requests while patched runtimes rolled out; that is not protection another Node deployment should assume it has.⁠⁸

The reverse proxy cannot inspect a response your application fetches directly from a third-party server.

If you have Python services or other Brotli consumers beside Node.js, check other software that decodes Brotli too. One operating-system library update does not necessarily repair copies bundled into application runtimes.

Patch Node.js, then retire the temporary controls

The patched Node.js release is the fix. For official upstream builds, move to 22.23.4, 24.22.1 or 26.12.1, or a later release in the same supported line, and restart the process. If your service is stuck on an end-of-life line, a line with no upstream fix needs a supported-runtime migration. Use the Node.js update and verification steps rather than treating a changed manifest as a deployed patch.

Do today

1. Inventory production Node.js processes and the parsers or HTTP clients that can decode Brotli.
2. Patch official upstream Node.js runtimes to a fixed release and restart each service where possible.
3. Set inflate: false on affected request parsers, or reject inbound Content-Encoding: br at the reverse proxy, when patching cannot happen immediately.
4. Verify that every intended entry point rejects the relevant compressed requests, and that legitimate clients still work as expected.

Do this week

5. Rebuild container images and redeploy packaged runtimes; check vendor-backported builds against their advisories.
6. Audit fetch() and other HTTP clients, especially features that retrieve user-supplied URLs.
7. Move body parsers behind authentication where feasible, without treating authentication as a fix for malicious compressed data.
8. Investigate suspicious restarts, decoder errors or unexpected child processes if unpatched endpoints were reachable; preserve logs and review possible compromise.

Can wait

9. Defer framework replacement and middleware rewrites until the runtime patch is complete.
10. Remove temporary request filters after patch verification when they disrupt legitimate clients, then review the normal compression policy.