HAProxy is not vulnerable to HTTP2Shell (CVE-2026-111497)

A new vulnerability is making the rounds, affecting any applications that decompress content using the Brotli decoder. It started in Node.js, then moved through Python, curl, Envoy, Istio, .NET, Java, and several Linux distributions over the course of a week.

HAProxy Community and HAProxy Enterprise are not affected. 

No action is required on any version of HAProxy itself. It does not use or support Brotli; the only algorithms it supports (gzip, deflate, raw-deflate, and identity) come from a separate compression library with no Brotli code, and there is no Brotli decoder in HAProxy.

HAProxy itself is not vulnerable, but the applications behind it might be. If you run Node, Python, curl, Envoy, or Istio services behind HAProxy, those still need patching. The rest of this post covers what HTTP2Shell is and how HAProxy can help you block the attack vector while you patch.

What is HTTP2Shell?

HTTP2Shell (CVE-2026-111497) is an out-of-bounds write in the Google Brotli decoder, affecting versions 1.0.3 through 1.2.0 across all platforms. It carries a CVSS v4.0 score of 9.2 and is classified as CWE-787.

The flaw sits in the decoder's block-switch routine. It returns a plain boolean that conflates two different outcomes: "this stream is malformed" and "I need more input." The fast path discards the return value entirely. A crafted Brotli stream can exploit that confusion to write past the end of a working buffer. From there, an attacker can corrupt memory, leak data, crash the process, or run arbitrary code.

The bug lives in the shared Brotli library, so every runtime that bundles it inherits the flaw. The disclosure rolled out in waves:

• October 21 — Node.js

• October 22 — Python (Brotli and brotlicffi)

• October 23 — Envoy, Istio, Bun, and libbrotli

• October 24 — Java (brotli4j) and Amazon Linux

• October 25 — .NET

• October 26 — Debian and Alpine; Fedora and RHEL partially; Ubuntu and SUSE still pending

The attack works in both directions. A malicious client can attack a server that decodes a Brotli request body, and a malicious server can attack a client that decodes a Brotli response. So "just update one thing" doesn't work here, because the flaw sits in every HTTP stack that handles Brotli.

There is one detail to keep in mind: the vulnerability is in decompression, not compression. Software that only compresses with Brotli is not affected. Apache's mod_brotli is unaffected for exactly this reason, since it compresses responses and never decodes them. 

If you need the details, the CVE record and the OpenCVE entry are good starting points. For per-runtime guidance, see the Node.js write-up, the Python advisory (GHSA-9v8h-qqgm-4m35), and the upstream fix commit. The fix is Brotli 1.2.1, or a patched 1.0.10 or 1.1.1.

Protecting your applications

HAProxy sits in front of the affected applications. That position lets you block the inbound attack vector while you patch.

Add this to the frontend in front of the affected backends:

In this example:

• req.hdr(Content-Encoding) reads the request's Content-Encoding header, which states how the body is compressed. This is the inbound vector.

• -m str -i br dcb matches either br or dcb as a whole token, ignoring case. HAProxy splits a comma-delimited header value into tokens first, so br, gzip, br, br, gzip, and deflate, br, gzip all match, while hybrid and zebra do not.

• http-request deny status 415 rejects the request at the edge, before it reaches a backend that would decode it. The 415 status tells the client the body's encoding isn't accepted here. Use status, not deny_status because deny_status implies a built-in error file, and HAProxy has none for 415, so the configuration would fail to load.

This checks Content-Encoding rather than Accept-Encoding, because they do different jobs. Accept-Encoding says what a client can accept in a response, and every modern browser sends br there. Matching on it would reject normal traffic. Content-Encoding describes the body you're actually receiving, which is what you want to inspect.

This works the same way on HAProxy Community and HAProxy Enterprise.

Scope it to the backends that need it, and remove it once they're patched. This rule is for one situation: a backend is known to be vulnerable, and you can't patch it yet. Apply it only to those backends, not to your whole frontend. Leaving it in place blocks legitimate Brotli request bodies, so if any of your clients send them, the rule will reject them.

Three more things to know:

• It only covers inbound request bodies. If a backend fetches and decodes Brotli responses from a third party, that path stays open, and you have to fix it in the client.

• It matches br and dcb only. If another content coding turns out to be Brotli-based, add its token to the end of the rule.

• It's a stopgap. Patch the backends.

When the next library CVE lands, the same move applies: enforce the policy at the edge, scoped to the affected backends, until the patch ships. That's HAProxy enforcing security policy at the edge.

HAProxy as a security component

HTTP2Shell is a good example of why the edge is the right place to enforce policy. You can't chase a flaw like this across every runtime in your fleet, but you can enforce one rule, once, in front of all of them.

The same discipline shapes HAProxy's security features. HAProxy Enterprise handles web application firewall, bot management, DDoS protection, rate limiting, and threat detection, with centralized management through HAProxy Fusion Control Plane.

A small attack surface is a security property. HAProxy isn't affected by HTTP2Shell because it doesn't carry the code, and that's the point.

To see what HAProxy can do for your security posture, explore our security solutions.

Subscribe to our blog. Get the latest release updates, tutorials, and deep-dives from HAProxy experts.