On October 27, 2026, CISA added CVE-2026-111497 to its Known Exploited Vulnerabilities (KEV) Catalog, citing evidence of active exploitation. The notice makes the flaw a priority for teams running vulnerable Brotli decoders, but does not describe the scale or outcome of the activity.

What the KEV listing means

CVE-2026-111497 is an out-of-bounds write in the Brotli decoder bundled with Node.js. An out-of-bounds write occurs when software writes data beyond the memory space reserved for it. Node.js says malformed Brotli input can crash a process, expose process memory or potentially enable remote code execution.

The KEV addition is the latest change in the vulnerability’s status. CISA’s October 27 notice cites evidence of active exploitation; it does not say how many attacks occurred or whether they resulted in successful compromises or code execution.

Which Node.js versions fix the flaw?

The Node.js project fixed the vulnerability in these supported release lines:

Node.js release lineFixed version
22.x22.23.4
24.x24.22.1
26.x26.12.1

Node.js says end-of-life versions are affected when it issues a security release. Operators should identify the runtime line used by each application and move to its corresponding fixed build.

When does Brotli decoding create exposure?

Exposure requires attacker-controlled Brotli data to reach a vulnerable decoder. Using Brotli to compress data, by itself, does not meet that condition.

A direct node:zlib call can decode the data, but an application does not have to call zlib itself for decoding to occur. Node.js fetch() can decompress Brotli responses, and Express 5 with body-parser can decompress request bodies when configured to do so. A basic Node.js HTTP server does not decode an incoming Brotli body merely by receiving it.

That makes the relevant inventory broader than a search for explicit decoder calls. Check response-handling code, configured request middleware and any proxy or application settings that enable decompression. The key question is whether untrusted Brotli input can reach a vulnerable runtime’s decoder.

What Imperva reported in its test

In a report published October 22, Imperva said it achieved code execution in tests using the official Node.js 24.22.0 Linux arm64 image. Its tested paths included Node.js fetch() and configured Express 5/body-parser request parsing. The tests required multiple attempts, and the same inputs were rejected on Node.js 24.22.1.

That result is specific to the tested runtime, architecture and application paths. It gives operators a concrete example of the risk without establishing that exploitation works the same way across every Node.js build or deployment.

Updating deployed applications

Update the affected runtime or library, then rebuild and redeploy any container or self-contained application that bundles its own runtime. Restart services and check the version running in each workload; updating a shared host runtime does not necessarily replace a separate copy packaged with an application.

Rejecting Brotli request bodies at a proxy or disabling request decompression can reduce exposure on inbound paths. Those controls do not protect a client that still decodes an attacker-controlled Brotli response. Removing br from Accept-Encoding alone is also insufficient, because a server can still send a Brotli response.