Critical Node.js RCE Vulnerability (CVE-2026-111497): Detection and Mitigation

TL;DR
- What: CVE-2026-111497 is an out-of-bounds write in the Brotli decoder bundled with Node.js. Node.js says it can allow remote code execution as the Node user and rates it high.
- Affected: Node.js 22.x, 24.x and 26.x. End-of-life 20.x and older likely carry the same code and get no fix.
- Fixed in: 22.23.4, 24.22.1 and 26.12.1, released October 21.
- Exposed: any workload that decompresses Brotli data it doesn't control, including responses decoded automatically by fetch(), axios and got.
- Exploitation: a public proof-of-concept reaches code execution on some test builds.
How OLIGO Helps
Patching is a business process that takes time. OLIGO catches exploitation of this flaw as it happens, inside the workload under attack.
Runtime Protection observes application and system activity inside running workloads. Oligo CADR detects exploitation of CVE-2026-111497 in real time.
Here’s what that looks like:
A crafted Brotli payload reaches a Node.js server, and Oligo raises a critical detection: Code execution through Node.js zlib decompression, mapped to MITRE ATT&CK Initial Access (Exploit Public-Facing Application).
The call stack shows the exact moment the attack turns. Execution reaches the flagged _close function in node:zlib, and runs straight into child_process.execSync and a clone syscall. Decompression code has no reason to start a process.

Oligo ties the detection into a single incident. The attack graph follows it end to end: from node server.js, through code execution in the zlib close path, to a shell running id and writing to /tmp. Your team sees the affected cluster, image and workload in one view, ready for triage.

Runtime Posture identifies every workload running an affected Node.js version across your environment, including runtimes baked into base images and sidecars that rarely show up in application manifests. That gives your team a patch list ordered by what is live in production.
Reach out to your OLIGO contact if you'd like help scoping exposure or walking through detections.
What Happened
Brotli is Google's compression library. Node.js bundles its own copy in deps/brotli and exposes it through the node:zlib module. When the decoder receives malformed compressed input, it can write past the end of its memory buffer.
That write happens in native C code inside the Node.js process. A crafted payload can corrupt memory, and Node.js says that can lead to code execution. At minimum, an attacker can crash the process.
The fix is an upstream patch from the Brotli project (commit 0ed4268a) that makes the decoder reject invalid input before it writes past the buffer. Brotli shipped the same fix in 1.2.1, 1.1.1 and 1.0.10. The change first landed in Brotli's source in February 2026 but only shipped as a security release on October 21.
Version Number vs. Exposure
Running an affected Node.js version makes exploitation possible, but it doesn’t automatically mean it is likely. Attacker-influenced data has to reach a Brotli decompress call, and compression-only use doesn't expose the bug.
The catch is how often that call happens without anyone writing it. fetch() (through undici) and popular HTTP libraries such as axios and got decompress Content-Encoding: br responses automatically. Common paths to the decoder:
- HTTP clients fetching from any server an attacker controls or can tamper with
- Servers that decompress request bodies
- Proxies and API gateways
- Workers that process uploaded or stored compressed objects
So checking whether your code imports zlib won't answer the question. What matters is which running workloads decompress data from sources you don't control.
Three more details shape scope:
- End-of-life lines. Node.js 20.x and older get no fix and most likely contain the same code.
- Distribution builds. Some Linux distributions build Node.js against the system's shared libbrotli. There, the fix may arrive in the OS brotli package rather than in Node.js. Debian's tracker lists nodejs in Debian 12, 13 and 14 as affected, with no fix yet.
- Other software. The fix came from upstream Brotli, so anything else that bundles the same Brotli version may be vulnerable too, even though this CVE covers only Node.js.
Recommended Actions
- Detect exploitation as it happens. OLIGO raises a critical detection, Code execution through Node.js zlib decompression, the moment decompression code starts spawning processes.
- Prioritize upgrades by what runs. OLIGO identifies which running workloads use an affected Node.js version, so patching starts with what is live in production.
- Upgrade Node.js. Move to 22.23.4, 24.22.1 or 26.12.1. Include base images, CI runners and serverless runtimes, which often pin Node.js separately from application code.
- Move off end-of-life lines. Workloads on 20.x or older won't receive this fix and should move to a supported line.
- Patch the most exposed workloads first. Internet-facing services that decompress request bodies, and services that fetch from third-party or user-supplied URLs (webhooks, link previews, scrapers, proxies).
The same releases fix three more high-severity issues (two TLS hostname-check bypasses and a dns.resolve null-byte truncation) and block eight compromised eMudhra intermediate certificate keys. Upgrading covers all of them.
Don't Wait for the Patch
What protects your business until the patch is deployed? And what happens when attackers use AI to study fixes and hunt for bypasses?
You can't patch fast enough to stay ahead of that. You need to detect and block the exploit.
This is what the industry keeps missing: you don't need to know a CVE exists to detect and block an attack. Exploitation leaves a trail at runtime. A process spawns a shell, a workload opens a connection it never opens, a file lands where it shouldn't. OLIGO detects and blocks that activity as it happens, whether the flaw behind it has a CVE or not.
If your team is working through these Node.js fixes alongside PHP2Shell, book a demo to see how OLIGO catches exploitation at runtime while your business keeps running – and how we help you prioritize remediation based on what actually runs in your environment.
