Brotli decoder flaw brings Node.js fixes and a wider dependency review

A high-severity decoder issue

The Node.js Project classifies CVE-2026-111497 as high severity. That is the stated rating; there is no need to replace it with an unsupported numeric critical score.

Node.js says malformed Brotli input can cause a crash, disclosure of process memory or remote code execution. These are different potential outcomes. A demonstration of one outcome in one environment should not automatically be presented as proof of the same outcome across every application that uses the decoder.

The Node.js security release lists fixed downloads 22.23.4, 24.22.1 and 26.12.1. Administrators should match the relevant fixed release to the application they operate. A version appearing in this list does not describe every separately bundled copy of Brotli elsewhere in an organisation.

What independent testing demonstrated

Imperva demonstrated code execution in the official Node.js 24.22.0 Linux arm64 image. The environment is part of the finding. Removing that detail would turn a concrete demonstration into a broader claim about platforms that the supplied evidence does not establish.

Imperva found that Node.js 24.22.1 rejected the same malicious inputs. This is useful evidence about those inputs and that tested release. It should not be extended into a claim that every intermediate component or platform received equivalent test coverage.

The reachable input paths also deserve attention. Imperva tested both Brotli-compressed responses consumed by fetch() and incoming request bodies handled by configured parsers. A review limited to inbound requests would overlook one of the paths in this testing. The practical task is to identify which paths an application actually uses.

The dependency question extends beyond Node.js

JFrog identifies affected upstream ranges as Brotli 1.0.3 before 1.0.10, 1.1.0 before 1.1.1, and 1.2.0 before 1.2.1. These are upstream Brotli ranges, not another set of Node.js release numbers. Keeping the two version namespaces separate is essential to a useful inventory.

JFrog reproduced a ClickHouse crash with one crafted HTTP request carrying a 23 MB body. That is a crash demonstration. It should not be promoted into a claim of code execution in ClickHouse, nor into evidence that malicious actors exploited the issue in the wild.

A conditional review for Algerian application teams

For Algerian organisations operating affected software, begin by identifying which applications contain or bundle a Brotli decoder. Then map the relevant version, available backport or vendor update, and paths that accept attacker-controlled input. A system-library change should not be assumed to cover a separate bundled copy.

Record which application owner is responsible for each update. Where there is uncertainty, ask the application vendor for the precise applicability decision rather than infer it from the presence of a familiar package name. These facts do not establish an Algerian victim or a local installation count.

Verification should match the claim being made

The evidence supports urgency without exaggeration: the vendor describes serious potential outcomes, and independent researchers demonstrated specific behaviour in specified environments. A local remediation record should identify the component changed and the application tested. Demonstrated exploitability and confirmed malicious exploitation are different claims; only the former is established by the supplied research.

Frequently Asked Questions

Sources & Further Reading

• Node.js Project
• Imperva
• JFrog Security Research
• Brotli2Shell: Google Brotli decoder (CVE-2026-111497) — Tenable