· via dev.to (home feed)
OpenAI's Codex finds Brotli RCE in Node.js; Imperva demonstrates it on official build
Node.js patched a Brotli decoder overflow found by OpenAI Codex Security; Imperva demonstrated code execution on the official Node.js 24 arm64 image.

A decoder bug found by an AI security team
Node.js published a security advisory on October 21 for CVE-2026-111497, a memory-corruption flaw in the Brotli decompression code that the runtime ships. The advisory credits researchers from OpenAI Codex Security with the discovery, and on October 23 OpenAI described the issue on X as one that permits unauthenticated remote code execution in Brotli.
The danger was demonstrated rather than theorised. According to The Hacker News, Imperva executed code through the flaw on the official Node.js 24.22.0 image for Linux arm64, with no debugger and no custom build involved.
Eight bytes, overwritten
Brotli is the compression format behind Content-Encoding: br, and Node bundles its own copy of Google's decoder, reachable through the node:zlib module. Per the advisory's root-cause description, when the streaming decoder encountered an invalid block switch it mistook a permanent format error for a request for more input, and kept appending bytes to an internal buffer only eight bytes long. An attacker who feeds a crafted compressed stream can corrupt process memory, the advisory warns, which can result in a crash, disclosure of process memory, or remote code execution.
Severity ratings differ across reports. A write-up on dev.io notes that Node itself rates the bug high rather than critical, a characterisation The Hacker News shares, while Crypto Briefing printed a CVSS score of 9.2. The vendor rating is the safest guide.
The fix also has a longer history than the CVE suggests. The Hacker News reports the correction first entered Brotli's upstream source in February 2026, but it was only labelled as a security change in the October releases; the Brotli 1.2.1 changelog dated October 21 lists the CVE.
How a malicious stream reaches your process
Imperva's analysis, relayed in the dev.to write-up, identifies two exposure paths that require no direct call to zlib:
- Fetched responses. Node's built-in fetch() decompresses compressed responses, so any service that calls a third-party API, follows a webhook URL, or fetches an address supplied by a user can be fed a malicious stream whenever the responding server is under attacker control.
- Parsed request bodies. Express 5's body parsers decode Brotli-compressed bodies alongside gzip and deflate. Imperva reproduced code execution on Express 5.0.0 through 5.3.0 and body-parser 2.0.0 through 2.3.0. A bare node:http server is not affected unless middleware or application code performs the decompression.
The result needs some proportion. Imperva said execution took multiple attempts in its setup and that it tested only arm64 on the 24.x line. An earlier public proof of concept achieved code execution only on a deliberately weakened build, managing a crash and a limited memory read on standard builds. The Hacker News reported no exploitation in the wild as of October 22.
Patched versions and a hard EOL line
The October 21 releases fix the flaw in three lines:
- Node 22.x LTS: first fixed in 22.23.4
- Node 24.x LTS: first fixed in 24.22.1
- Node 26.x Current: first fixed in 26.12.1
Node 20 and older receive nothing. The advisory states plainly that end-of-life versions are always affected when a security release occurs and lists no workaround; upgrading is the remediation. The same release addresses nine other CVEs, three of them also rated high: two TLS certificate hostname verification bypasses and a dns.resolve truncation issue involving NUL characters.
The practical challenge is inventory. As Imperva points out, a package audit can miss an older runtime bundled inside a container, so the Node version in every deployed image, CI runner and VM needs checking directly. The dev.to write-up suggests pinning base images to fixed releases and rebuilding, and treating the engines field in package.json as documentation only, since npm merely warns on a mismatch.
WAFs are a partial shield
Vercel deployed WAF rules on October 21 that block the inbound attack for every project, and it manages patch levels for its 22.x and 24.x runtimes. Its bulletin is clear about the limits: the rules do not cover responses that functions fetch from other servers and do not replace patching, and projects still on Node 20 must move to 22 or 24. Imperva added its own WAF rules and likewise states that a Node.js update is required for full remediation, because an inbound filter never inspects what fetch() pulls from an external origin.
Why it matters
Three things lift this beyond a routine CVE. First, the finder was an AI security team, a notable instance of machine-assisted research surfacing a serious flaw in widely deployed infrastructure code. Second, the exposure is passive: the bug is reachable through ordinary fetch() calls and default Express body parsing, so developers who never touch zlib directly are still on the attack path. Third, Node 20 and older releases will never be patched, leaving a permanent population of vulnerable runtimes. Anyone running Node in production should verify the version inside every deployed image, not just on a laptop, and move to a fixed release.
- #node-js
- #security
- #brotli
- #remote-code-execution
- #openai