‹ FeedCybersecurity
Cybersecurity

Is nginx or Apache Vulnerable to Node2Shell?

Serving Brotli from nginx or Apache doesn't expose you to the decoder flaw by itself. Here is how to find what actually decodes Brotli behind your proxy.

7 min read

Serving Brotli-compressed pages through nginx or Apache does not, by itself, expose your web server to CVE-2026-111497. The flaw is in the decoder, which unpacks compressed data, while the standard web-server Brotli modules compress responses or serve files already compressed.⁠1⁠2 Think of sending a zipped file versus opening one: this bug is in the opening step. Check what decodes Brotli behind your proxy before deciding what to patch.

You're affected if a component in your stack uses a vulnerable Brotli decoder and processes Brotli data an attacker can control. You're not exposed through the documented response-compression functions of Apache's mod_brotli or nginx's ngx_brotli alone. A separate decoding module, system library or backend application can change that answer. CISA confirmed exploitation of CVE-2026-111497 on 27 October 2026. Status as of 4 November 2026.⁠3

The complete PHP2Shell and Node2Shell guide covers the vulnerability across software ecosystems. This page covers nginx, Apache and the applications running behind them.

What exactly is broken in Brotli?

CVE-2026-111497, also called Node2Shell or HTTP2Shell, is an out-of-bounds write in Google's Brotli decoder. The bug can corrupt process memory when an application decompresses untrusted Brotli data. Google's advisory lists crashes, memory disclosure and potential remote code execution as possible consequences.⁠4 It is not a flaw in the Brotli compression format itself, nor does generating a normal Brotli-compressed response exercise the vulnerable decoder.

The affected upstream Brotli releases are 1.0.3 through 1.0.9, 1.1.0 and 1.2.0. Google shipped the branch-specific fixes on 21 October 2026: 1.0.10, 1.1.1 and 1.2.1.⁠5 A fixed 1.1.1 build is therefore not vulnerable merely because it falls numerically inside the broad 1.0.3–1.2.0 advisory range.

Reported CISA added the CVE to its Known Exploited Vulnerabilities catalog on 27 October and set a federal remediation deadline of 10 November.⁠3 The entry confirms exploitation but does not identify nginx or Apache's standard compression modules as attack paths. The question for an operator is whether a vulnerable decoder is reachable, not whether Brotli appears anywhere in the configuration.

Does nginx or Apache decode Brotli by default?

Apache HTTP Server's mod_brotli provides the BROTLI_COMPRESS output filter. Apache's documentation says the module compresses content before sending it to the client and describes serving pre-compressed files as another option.⁠1 Neither operation requires decoding an incoming Brotli request body. The documentation does not describe a Brotli request-decompression filter supplied by mod_brotli.

nginx's commonly used Brotli support comes from the separate ngx_brotli project, not from nginx's standard built-in gzip module. Google's ngx_brotli README documents two modules: a filter that compresses outgoing responses and a static module that serves files ending in .br. Neither is documented as a request-body Brotli decoder.⁠2

Common misreading: "I use Brotli on nginx, so I'm vulnerable." Sending compressed responses does not mean nginx is unpacking untrusted Brotli data. The standard output modules do not establish a Node2Shell exposure by themselves.

There is one versioning detail worth keeping separate. Strobes classified ngx_brotli as already updated in its 24 October tracker, but Google's repository releases do not identify a specific CVE-2026-111497 module release.⁠6⁠7 That classification does not establish that the module's documented response-compression path was vulnerable. Check the actual module build and its Brotli dependency rather than applying a version number from a third-party table.

A third-party module, commercial server build or application extension that explicitly decodes Brotli needs its own assessment. The standard modules' documented behavior is not a guarantee about every possible nginx or Apache installation.

Where could the vulnerable decoder be?

Consider a site with this stack:

Browser → nginx reverse proxy → Node.js application

The browser requests a page. nginx receives the request, passes it to Node.js and may compress the outgoing response with Brotli before sending it back. That final compression uses an encoder. It does not exercise the decoder flaw.

The Node.js application has a different job. An Express 5 body parser can decompress an incoming Brotli request, while Node.js fetch() can decompress a Brotli response retrieved from another server. Datadog documented both paths on 29 October.⁠8 If the Node.js runtime carries a vulnerable decoder, those are the places to investigate. An nginx proxy that simply forwards compressed bytes does not make the decoder behind it safe.

Node.js fixed the vulnerability in upstream releases 22.23.4, 24.22.1 and 26.12.1 on 21 October.⁠9 The Express and body-parser mitigation guide explains how request parsing reaches the decoder and what can reduce inbound exposure until the runtime is patched.

Common misreading: "nginx isn't affected, so my site is safe." The proxy's compression module can be outside the vulnerable path while the application behind it remains exposed. You have to assess both.

Libraries installed on the same machine create another inventory problem. Red Hat's advisory distinguishes Node.js builds that use the system Brotli library from builds that bundle their own copy. For example, its RHEL 8 and 9 Node.js 22 packages use system Brotli, while its Node.js 24 modules use bundled Brotli.⁠10 Debian likewise documents that its packaged Node.js uses the system library.⁠11 Updating one copy does not automatically repair the other.

How you'd notice and check your server

Start with the web-server modules and configuration, then follow requests into the applications behind them. A normal Brotli-compressed response with Content-Encoding: br tells you that compression is working. It does not show whether the server ever decodes an untrusted Brotli stream. For inbound traffic, that same header is a useful lead only when it describes the request body.

For nginx, the documented nginx -V command prints the version and build-time configure parameters. nginx -T tests and dumps the configuration, which can expose dynamic module loading and compression settings.⁠12 For Apache HTTP Server 2.4, httpd -M lists loaded static and shared modules.⁠13 These commands establish what the server was built to support and what it loads. They are not vulnerability tests.

Then check the installed Brotli packages and backend runtimes. Compare the full distribution package release against its vendor advisory, not just the upstream library number. Debian 12, for example, records a fix in 1.0.9-2+deb12u1, while Debian 13 records 1.1.0-2+deb13u1.⁠11 Both retain older upstream-looking numbers because the security fix was backported.

If the inventory includes Python, .NET, Bun or software with a bundled Brotli decoder, use the cross-ecosystem Brotli inventory to identify the right patch owner. A scanner reporting no finding is useful evidence, but it cannot substitute for identifying which library copy a process actually loads.

Can blocking Brotli at the proxy protect the application?

A proxy can reduce one exposure path by rejecting incoming requests whose body uses Content-Encoding: br. Datadog recommends that measure when an affected runtime cannot be patched immediately, while warning that edge rules do nothing for malicious Brotli responses fetched by the application.⁠8 This is an inbound request-body control. It should be tested against every relevant route, including paths that might bypass the proxy.

It also changes application behavior. Legitimate clients sending Brotli-compressed request bodies will be rejected. A proxy rule can preserve other compression formats if it specifically blocks Brotli, whereas disabling inflation in an Express body parser rejects compressed request bodies more broadly. Neither measure repairs the underlying decoder.

Common misreading: "Disabling Brotli compression in nginx fixes it." Turning off outgoing compression does not remove a vulnerable Brotli decoder from Node.js, Python or another component. That follows from where the bug sits: the decoding operation remains available even if nginx stops producing Brotli responses.

Datadog describes an edge rule as a useful tripwire rather than a full defense.⁠8 Treat it accordingly. It can reduce what reaches a request parser, but it cannot inspect responses that an application retrieves directly from a remote server.

Check the decoder and patch its owner

Do today

  1. List nginx and Apache modules, including separately installed Brotli extensions and any modules that decompress incoming content.
  2. Identify backend applications and libraries that decode Brotli, especially request-body parsers and outbound HTTP clients.
  3. Compare installed runtimes and libraries against their own vendor advisories, including backported distribution packages.
  4. Patch vulnerable Node.js and Brotli decoder builds where updates are available; restart applications and rebuild containers when required.
  5. Reject inbound Brotli-compressed request bodies at the proxy as a temporary control if an exposed backend cannot be patched immediately.

Do this week

  1. Audit applications that fetch user-supplied URLs, including webhook testers, link-preview services and feed readers.
  2. Check whether a third-party nginx or Apache module contains its own Brotli decoder, rather than assuming its behavior from the standard modules.
  3. Review logs for unusual decoder failures, process restarts or sustained CPU usage associated with Brotli traffic. Treat those symptoms as leads, not proof of exploitation.
  4. Verify the running versions after deployment and remove temporary restrictions that break legitimate clients once the affected decoders are fixed.

Can wait

  1. Defer replacing nginx or Apache solely because they serve Brotli-compressed responses.
  2. Review response-compression settings later for performance or operational reasons. Disabling normal Brotli compression is not the primary remediation for this CVE.

FAQ

The documented ngx_brotli modules compress responses or serve pre-compressed files. They do not, by themselves, expose the vulnerable decoding operation. A separate decoder, bundled library or application behind nginx still needs checking.

Apache documents mod_brotli as an output compression module. Its normal response-compression path does not use the flawed decoder. Other Brotli-consuming software on the same server may still be affected.

It depends on how Node.js was packaged. Red Hat and Debian both document builds that use the system library, but other Node.js builds bundle their own decoder. Match the runtime to its vendor advisory and apply the relevant fix.

It can reduce exposure through incoming compressed request bodies. It does not protect an application that fetches and decompresses a Brotli response from another server, and it is not a substitute for patching the affected decoder.

You've reached the end

Is nginx or Apache Vulnerable to Node2Shell?

Back to the feedRead the full article

The full article has comments, related reading and sharing.