CVE-2026-111497: From Node2Shell to HTTP2Shell in Node, Python, and curl

⏱️ Reading time: 8 min

Node2Shell was born on Wednesday, October 21, as a specific Node.js bug. Forty-eight hours later it mutated into HTTP2Shell and reached any library or server that compresses HTTP traffic with Brotli, from Python to curl, Bun, and Envoy.

📑 En este artículo

1. TL;DR
2. What Is Brotli
3. What Happened: From Node2Shell to HTTP2Shell
4. Context and History: OpenAI’s Silent Discovery
5. Technical Details: How a Small Buffer Allows Code Execution
6. Impact and Analysis of the Brotli Vulnerability
7. What’s Next
8. Frequently Asked Questions
   1. What is CVE-2026-111497?
   2. What’s the difference between Node2Shell and HTTP2Shell?
   3. Is my Apache or Nginx server exposed to this Brotli flaw?
   4. How do I know if my project uses a vulnerable version of Brotli?
   5. Why don’t pip-audit or Dependabot detect the Node2Shell/HTTP2Shell flaw?
   6. Which Node.js versions fix CVE-2026-111497?
9. References

The root cause is CVE-2026-111497, a memory overflow in Google’s official decoder that lets an unauthenticated attacker corrupt processes and, in the worst case, execute remote code. OpenAI says it found this in February. No one registered it as a vulnerability until this week.

TL;DR

• CVE-2026-111497 is an overflow in the Brotli decoder that allows unauthenticated remote code execution.
• Node2Shell (Node.js, October 21) evolved into HTTP2Shell: it also affects Python, C++, curl, Bun, and Envoy.
• OpenAI says it found the bug in February 2026 and reported it as a bidirectional client-server RCE.
• The flaw reaches a CVSS v4.0 score of 9.2 (critical) in Brotli 1.0.3 through 1.2.0; the safe version is 1.2.1.
• Apache and Nginx don’t decode Brotli by default, but clients like requests and httpx load the vulnerable library.

What Is Brotli

Brotli is the lossless compression algorithm Google designed to reduce the size of HTML, CSS, and JavaScript on the web; browsers and servers use it to compress HTTP content. The Brotli vulnerability revealed this week hits precisely its decoder and allows memory corruption or unauthenticated remote code execution.

The reference implementation lives in Google’s official repository. Node.js, Python, curl, and dozens of languages don’t rewrite the decoder from scratch: they bundle a copy of that code inside their own libraries. That’s why a single flaw at the source multiplies across dozens of different projects.

What Happened: From Node2Shell to HTTP2Shell

The Node.js team named the flaw Node2Shell on Wednesday, October 21, and described it as an out-of-bounds write in the Brotli decoder that the runtime bundles between versions 1.0.3 and 1.2.0. A remote, unauthenticated attacker can send a manipulated Brotli stream and corrupt the memory of the process decompressing it.

On Thursday the 22nd, Python confirmed that its Brotli and brotlicffi packages load the same vulnerable native library. By Friday the 23rd it was clear that curl, Bun, Envoy, and Istio also include it. Hence the name change: HTTP2Shell better describes a flaw that affects any platform (Windows, macOS, Linux), because it lives in the algorithm and not in any particular operating system.

Between 4:12 and 4:15 p.m. Pacific time on Friday the 23rd, patches began appearing for libbrotli, Python, C++, Node.js, and Bun, and OpenAI published that it had discovered the same bug in February.

The change that sent half the ecosystem scrambling is clear in a typical requirements.txt:

-brotli==1.2.0
-brotlicffi==1.2.0.0
+brotli==1.2.1
+brotlicffi==1.2.1.0

That version bump is enough for pip show brotli brotlicffi to stop reporting a version within the 1.0.3-1.2.0 range, which is the range CVE-2026-111497 marks as vulnerable.

Context and History: OpenAI’s Silent Discovery

OpenAI says it found this bug in February 2026 and reported it as an unauthenticated remote code execution that works in both directions. A malicious client can take control of an unpatched server, and a malicious server can take control of a client that accepts compressed responses.

The Brotli team fixed the root cause in the source code that same month, but no one registered it as a security vulnerability, according to Aikido Security’s analysis. That eight-month gap explains why no automated scanner detected it: the fix existed in the repository, but no published version included it until Node.js reacted this week.

The bidirectional mechanics are the most uncomfortable part of the case. The server doesn’t need to be exposed to the internet to be at risk: an HTTP client that downloads a compressed response from an attacker-controlled site also runs the vulnerable decoder, so the attack surface includes developers who simply browse or scrape from their own machine.

Technical Details: How a Small Buffer Allows Code Execution

The bug lives in the routine that decodes a Brotli stream byte by byte. The decoder should reject a stream that declares more data than the format allows, but a bounds check fails and it keeps accepting extra bytes.

Those extra bytes get written over a fixed-size working buffer allocated on the heap, and whatever overflows tramples neighboring memory structures. An attacker who controls the content of the Brotli stream also controls which bytes overwrite that memory. With enough precision, that translates into arbitrary code execution instead of a simple process crash.

The CVSS v4.0 score of 9.2 reflects that lack of prerequisites: no authentication is needed, no user interaction is needed beyond receiving a compressed response, and the impact covers confidentiality, integrity, and availability at once.

The following sequence summarizes the attack: a corrupt Brotli stream enters the decoder, the size limit check fails, and the overflow corrupts memory that the attacker can exploit to execute their own code.

sequenceDiagram
participant A as Attacker
participant S as Node.js Server
A->>S: manipulated Brotli stream
S-->>S: decodes and overflows the buffer
Note over S: neighboring memory corrupted
S-->>A: executes attacker's code

The following table summarizes patch status by project as of October 23, 2026, according to Aikido Intel’s tracking:

Impact and Analysis of the Brotli Vulnerability

The Brotli vulnerability gets a CVSS v4.0 score of 9.2, critical, because it requires no authentication and compromises both clients and servers. The aggravating factor is the dependency chain: packages like requests, httpx, and aiohttp load Brotli automatically when it’s installed, even though the developer never explicitly requested it.

As of October 23, advisory databases still hadn’t linked the CVE to the PyPI packages, according to the same Aikido analysis. That means tools like pip-audit, Dependabot, and Safety weren’t flagging the vulnerable versions that day. Anyone relying solely on an automated scanner could believe they were safe without actually being so.

Not every server is exposed equally. Apache’s standard mod_brotli module and Nginx’s default configuration don’t decode incoming Brotli, they only compress it on the way out. Neither one runs the vulnerable decoder unless an additional module enables it.

⚠️ Heads up: if your library or application doesn’t have a patch available yet, the recommendation is to disable Brotli decoding until it does, not wait without mitigating.

What’s Next

The list of affected projects will keep growing in the coming days. Any language or framework that bundles a static copy of Brotli between versions 1.0.3 and 1.2.0 needs to review its dependency chain, not just its main runtime.

The Brotli vulnerability also forces a rebuild of any container image that includes an old copy of the library. The bug lives in the bundled binary and isn’t fixed just by updating the base operating system; it requires rebuilding and redeploying.

Linux distribution maintainers are still packaging the OS-side backport, and managed service providers have to confirm remediation case by case before their customers can consider themselves safe.

Try it yourself: run pip show brotli brotlicffi on your Python environments right now and confirm the installed version is 1.2.1 or later.

Frequently Asked Questions

What is CVE-2026-111497?

CVE-2026-111497 is the official identifier for a memory overflow in the Brotli decoder, with a CVSS v4.0 score of 9.2, that allows unauthenticated remote code execution.

What’s the difference between Node2Shell and HTTP2Shell?

Node2Shell was the initial name, limited to Node.js. HTTP2Shell is the same bug recognized as a problem affecting any library or service that decodes Brotli over HTTP, including Python, C++, curl, Bun, and Envoy.

Is my Apache or Nginx server exposed to this Brotli flaw?

No, if you’re using the standard configuration. Apache’s mod_brotli and Nginx’s default configuration don’t decode incoming Brotli, so they don’t run the vulnerable routine unless an additional module enables it.

How do I know if my project uses a vulnerable version of Brotli?

Check whether you have Brotli 1.2.0 or earlier installed, or brotlicffi 1.2.0.x. In Python, run pip show brotli brotlicffi; in a Node.js project, npm ls brotli.

Why don’t pip-audit or Dependabot detect the Node2Shell/HTTP2Shell flaw?

Because, as of October 23, vulnerability databases still hadn’t linked the CVE to the specific PyPI packages. A scanner that depends on those databases can’t flag what hasn’t been cataloged yet.

Which Node.js versions fix CVE-2026-111497?

Node.js fixes the flaw in versions 22.23.4, 24.22.1, and 26.12.1, or in any newer release on those same lines.

References

• Aikido Security: original coverage of how Node2Shell evolved into HTTP2Shell and patch status by project.
• NVD: official record for CVE-2026-111497 with the CVSS score and affected versions.
• google/brotli: official repository for the algorithm and the reference implementation of the decoder.
• Node.js: the runtime’s official site, which published versions 22.23.4, 24.22.1, and 26.12.1 with the patch.

📱 Like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.

Featured image: Foto de Markus Spiske en Unsplash