Infrastructure

Node.js plans high-severity security fixes for November 11

The Node.js project plans updates for the 22.x, 24.x, and 26.x release lines on or shortly after November 11.

Node.js logo above a green shield with a keyhole and circuit traces.
DevInk editorial artwork generated with OpenAI, using Node.js branding as a reference. Source: Node.js branding (opens in a new tab).

The Node.js project plans to release security updates for Node.js 22.x, 24.x, and 26.x on or shortly after Wednesday, November 11. The highest severity rating is High for each release line. The advance notice gives teams time to prepare while the CVE IDs, affected components, and exact patched versions are still pending. Node.js November security notice

Which Node.js release lines are covered?

Node.js 26.x, known as Lithium, entered active long-term support on October 28. Node.js 24.x and 22.x are in maintenance LTS, a phase in which the project still ships security updates and critical bug fixes. Teams on either maintenance line can plan for a patch within their current major version. Teams running an end-of-life line such as 20.x need to plan a move to a supported release. Node.js release schedule

What the October releases already addressed

On October 21, the project shipped Node.js 22.23.4, 24.22.1, and 26.12.1 with fixes that included a vulnerability in the bundled Brotli decoder, tracked as CVE-2026-111497. An application that passes attacker-controlled Brotli data to node:zlib can trigger a write past the end of a decoder buffer. The resulting memory corruption can crash the process, expose data from memory, or allow remote code execution. October security advisory

Those October releases also updated the bundled certificate data in response to the eMudhra intermediate certificate authority compromise. That change concerns which certificates the runtime trusts when it verifies a TLS connection. Both October fixes are already available, so teams still running affected builds can act ahead of the November release. October security advisory

What production teams can do before November 11

Start with the version actually running in production. Check the deployed runtime with node --version and trace where it comes from. A service may use Node.js from its final container image, a managed runtime, or a host package. A version bump in CI can leave production running the same binary.

For containerized services, check the base image in the final Dockerfile stage as well as the build stage. Identify which images need rebuilding and which services need redeploying. Include workers and scheduled jobs in that inventory if they ship separately from the main application.

What to check when the patches ship

Use the updated advisory to identify the fixed build for each major version you run and review any conditions that affect your applications. Rebuild or update the runtime, run your usual release checks, and verify the version in the deployed environment after rollout. The Node.js project also maintains a mailing list for security announcements. Node.js security announcements

Go to the source