Node.js fixes critical remote code execution flaw in Brotli and nine more vulnerabilities

The announcement

The Node.js project released security updates this Wednesday (11/11) for the runtime's three active lines (22.x, 24.x, and 26.x), fixing ten vulnerabilities. One of them is rated critical: a flaw in the Brotli compression decoder that allows remote code execution. The others are high severity and affect distinct areas of the runtime, from DNS resolution to TLS certificate verification.

According to PaqSec's material on the release, the advisory was issued ahead of time specifically to give teams time to plan the patch rollout before the corrected binaries were delivered. A video from the weekly roundup Código Fonte TV, which covers programming, technology, and cybersecurity, sums up the reason for the early notice:

The advisory was issued early specifically to try to give teams time to plan the application of patches against high-severity flaws across the three version branches.

Código Fonte TV roundup, episode on Node.js security

The critical flaw: CVE-2026-111497 in Brotli

The most serious issue in the package is CVE-2026-111497: an out-of-bounds write problem in the Brotli decoder, a compression library used internally by Node.js. This type of memory corruption flaw can crash the process or, in the worst case, open the door for an attacker to execute arbitrary code on the affected server or machine.

This isn't the first time: back in October, the project had already fixed a similar flaw in the same component, informally nicknamed "Node to Shell" by the Código Fonte TV video. That vulnerability was also in the Brotli decoder, integrated into Node.js's native zlib module, and it likewise caused memory corruption with the potential for remote code execution. In practice, this means Brotli has become, over the past two months, the most targeted component in the runtime's security rounds.

The other nine vulnerabilities

Beyond the Brotli flaw, the patch set covers a varied range of points in the runtime, according to PaqSec's material:

• Domain bypass via truncation in DNS queries;
• Flaws in TLS certificate verification;
• Problems in HTTP connection handling;
• Errors in ZIP file processing;
• Flaws in filesystem permission checks.

The project did not disclose the exact count of flaws per component, individual identifiers (besides the CVE for the critical flaw), or details about attack methods or evidence of active exploitation. This practice is common in security advisories: withholding technical details until the corrected binaries are available reduces the chance that someone uses the information to build an exploit before the ecosystem has time to update.

Patched versions

The fixes arrived as one version per active line, each receiving at least the fix for the serious vulnerability reported for its branch:

Under the project's current support structure, the 26.x line operates as Active LTS, while 24.x and 22.x remain in maintenance mode, receiving only critical fixes like this one. Older versions that have already reached end of life are not covered: the project does not backport security patches to unsupported branches.

Node doesn't have PHP's leniency

The Código Fonte TV video draws a comparison worth noting: when discussing an incident of similar severity in the PHP ecosystem, the host recalls that the PHP community chose to apply security patches even to old versions, given the scale of the problem. Node.js, according to the video, does not adopt this policy: anyone on a version outside the support cycle simply does not get the fix, no matter how critical it is.

In practice, this shifts the burden of updating onto whoever maintains the application. Staying on an EOL Node.js version isn't just about losing access to new features: it means running in production without a safety net against flaws like the one in Brotli, even when it allows remote code execution.

What changes in practice for developers

The direct recommendation is to update development and production environments to 22.23.4, 24.22.1, or 26.12.1, depending on the line in use, as soon as possible. It's worth a reminder about a detail that often goes unnoticed: anyone running the application in a container needs to update the base image, not just redistribute the same artifact. Doing a new deploy without swapping the Node.js image inside the Dockerfile doesn't fix anything.

It's also worth remembering those who use Node.js without realizing it: many build tools, CLIs, or development environments run on the runtime under the hood, even when the main project is on a different stack. Checking the node version installed locally and in CI pipelines is part of the process, not just on production servers.

What remains open

The project did not disclose the full list of CVEs beyond the critical Brotli flaw, nor did it indicate whether there is active exploitation of the other high-severity flaws. This means each team's risk assessment, for now, needs to assume the most conservative scenario: treating the nine remaining vulnerabilities as potentially serious until more technical details are published. The ideal approach is not to wait for that level of detail before applying the patch.