Node.js October Security Update: Patch the Runtime, Not Just npm Packages
You installed Node.js 24.22.1, and a new terminal reports the patched version. Is the web service that started before the update actually running it?
- The October 21 security releases are 22.23.4, 24.22.1 and 26.12.1. You can patch the release line you already use.
- The Brotli issue concerns attacker-supplied compressed data processed through
node:zlib. The advisory's highest severity is High. - Check the runtime that actually starts your service. Updating application dependencies is a separate job.
npm audit checks the dependency tree
According to the npm audit documentation, the command submits project dependency information to a registry and requests a report of known vulnerabilities. Its fix mode applies remediations to the package tree.
A clean report therefore does not prove that the Node.js executable running your application contains this release's fixes. For example, a deployment can have a freshly updated lockfile while still launching the application with an older runtime. In a container deployment, check the image supplying Node.js as well as the packages installed inside it.
You do not need a major-version migration to get these fixes
Node.js shipped security updates for three release lines on October 21. Existing Node.js 22 and 24 applications have their own patched releases; moving every application to 26 is not a prerequisite.
| Release line | October 21 fixed release | Status on its release page |
|---|---|---|
| 22.x | 22.23.4 | LTS |
| 24.x | 24.22.1 | LTS |
| 26.x | 26.12.1 | Current |
The release notes cover more than compression: DNS, TLS, HTTP and permission checks also appear in the fixes. Avoid turning a finding that one application does not use Brotli into a conclusion that the entire security release is irrelevant.
The Brotli flaw depends on a decompression path
The Node.js advisory describes CVE-2026-111497 as an out-of-bounds write in its bundled Brotli decoder. Malformed data supplied by an attacker and decompressed through node:zlib can corrupt process memory, potentially causing a crash, memory disclosure or remote code execution.
That is a concrete input-processing condition, not a claim that every running Node.js server is automatically compromised. The affected release lines listed for this issue are 22, 24 and 26.
Verify the executable used by the service
This command prints the version and executable path of the Node.js process it launches:
node -p "process.version + ' | ' + process.execPath"The official API defines process.version as the Node.js version string and process.execPath as the absolute path of the executable that started the process. A result from a new terminal is evidence about that invocation. It does not describe every service already running on the machine.
For a deployment check, identify the runtime selected by the service configuration or container image, update it through the application's normal deployment process, and verify the replacement service's version and path. Follow with the application's request-handling and outbound-connection checks.
Frequently asked questions
Must a Node.js 24 application move to 26?
No. The October 21 release includes 24.22.1, so patching the 24 line can be handled separately from a major upgrade.
Does zero vulnerabilities in npm audit close this issue?
No. That result covers the project's dependency audit. You still need evidence about the runtime used by the deployed service.
The completion criterion is a service running the fixed runtime, not merely a successful package update.