Node.js patches 10 vulnerabilities including high-severity Brotli decoder RCE

Security releases for all supported lines

On October 21, 2026, the Node.js project shipped security releases for its three supported release lines, according to a dev.to write-up. The advisories cover 10 vulnerabilities: four rated High, three Medium and three Low. The patched versions are v26.12.1 for the 26.x line, v24.22.1 for 24.x, and v22.23.4 for 22.x.

No workarounds are listed for any of the issues, so the upgrade is the fix. Node.js 20 and earlier are end of life and will never receive these patches; the only route there is moving to a supported line. Container images pinned to an old tag stay vulnerable until rebuilt, and every Node process, containers included, needs a restart to load the patched runtime. The dev.to author also notes that distribution-packaged builds may link against the system Brotli library, so anyone running their distro's Node package should check the vendor advisory as well.

The Brotli decoder flaw

The urgent item is CVE-2026-111497, a High-severity out-of-bounds write in the Brotli decoder bundled with Node.js. As the advisory describes it, the decoder mishandled an invalid block switch, treating the stream as if more input were required rather than rejecting it, which let the streaming decompressor keep writing into a small internal buffer. Malicious Brotli data fed to node:zlib decompression can crash the process, disclose memory, or result in remote code execution.

Exposure comes down to whether untrusted Brotli data can reach the process. Testing on Node.js 22.22.0 described in the write-up found that fetch() automatically decodes Brotli-compressed responses, so any server the code fetches from, including user-supplied URLs or webhooks, can deliver Brotli data. A plain http server does not decode request bodies, but Express 5 with body-parser 2 parses a Brotli-compressed JSON body with no extra configuration, which matches what security firm Aikido reported. Apps running Express 5 or calling fetch() against servers they do not control should assume they are exposed.

Exploitability reports disagree

Public reporting splits on how practical exploitation is. Hacker News discussion cited by dev.to says a public proof of concept appeared on October 22 and achieved code execution only against a deliberately weakened test build, producing a crash and a limited memory read on a standard build. Aikido reports achieving code execution against an unmodified Node.js 24.22.0 image on Linux arm64, though not on every attempt, and says 24.22.1 rejects the same input. Neither side reported in-the-wild exploitation as of October 22, and Qualys notes the CVE records did not yet carry CVSS scores.

TLS verification and DNS edge cases

Three further issues sit in how tls.checkServerIdentity() decides that a certificate matches the host being contacted. The advisory frames them as IP-address edge cases: an address written with fullwidth digits, leading zeros, hex notation or as a bare integer gets matched against DNS names in the certificate rather than its IP entries. The dev.to write-up illustrates the parsing gap: WHATWG URL handling reads 0127.0.0.1 as octal, yielding 87.0.0.1, while some operating system resolvers read it as decimal. A certificate can therefore be validated against a different address than the one the socket actually connects to. These flaws matter most to services that dial others by IP address or accept hostnames and URLs from users.

CVE-2026-105482 makes dns.resolve*() and dns.reverse() cut a name off at an embedded NUL byte, because the name is handed to c-ares as a C string; the advisory's example is that attacker.example\0.trusted.example resolves attacker.example. The risky pattern is validating a hostname against an allowlist and then resolving it, a common SSRF defence, and the advisory calls this an incomplete follow-up to CVE-2026-48930.

The remaining fixes cover a keep-alive socket that treats early-arriving data as the response to the next request, DNS names in certificates that authenticate non-canonical IPv4 spellings, and cached crypto.randomUUID() and randomInt() state baked into startup snapshots and single-executable apps, all rated Medium. Three Low issues address a zlib.ZipFile edge case on Node 26 and two Permission Model weaknesses. The release also refreshes c-ares, undici, the CA certificate bundle (the advisory lists an "eMudhra Intermediate CA Compromise"), OpenSSL on the 24.x and 22.x lines, and SQLite on 22.x.

A stopgap, not a substitute

Teams that cannot upgrade immediately can, per the dev.to author's tested suggestion, add Express middleware that rejects Brotli request bodies with an HTTP 415 before any body parser runs, or enforce the same rule at a proxy or load balancer. This covers neither Brotli responses the app fetches from other servers nor the other nine vulnerabilities, so it is a stopgap only.

Why it matters

A memory-corruption flaw in a runtime that routinely handles untrusted network input, with a public proof of concept already circulating and a routine version bump as the remedy, is a patch-now problem regardless of the disagreement over exploitability. The exposure paths are ordinary ones, fetch() calls and Express 5 body parsing, not exotic configurations, and end-of-life lines will never receive this fix. Checking node --version across servers, CI runners and container images, then upgrading and restarting, is the entire remediation.