A security update can look finished surprisingly early. The version file has changed, the pull request is green, and someone has installed the new runtime locally. Meanwhile, a production container may still be running yesterday’s image.
The Node.js releases published on 11 November make this a good week to close that gap. The project has released security updates for its supported 22, 24 and 26 lines. For teams running Node in production, the useful question is straightforward: which runtime is actually serving requests?
What changed this week
The released versions are 22.23.5, 24.22.3 and 26.13.1. Each official release page identifies it as a security release, so this is more than a routine feature update. These are the versions associated with this particular advisory, rather than a promise that they will remain the latest patches. (Node 22 release, Node 24 release, Node 26 release)
The advisory covers several high-severity issues around HTTP/2 and TLS. Depending on the affected feature and application configuration, the consequences include process crashes, resource leaks, memory disclosure and a client-certificate authentication bypass. The conditions differ between issues, so it would be misleading to describe every Node application as equally exposed. (Official security advisory)
That makes deployment architecture relevant. Check whether Node handles TLS or HTTP/2 itself, which networking features the application uses, and where a proxy or hosting platform sits in the path. Use those answers to assess urgency, without treating an architectural assumption as proof that patching can wait.
Start with an inventory
Start with a short list of the places Node runs: production services, background workers, scheduled jobs, CI runners and build images. Record the version and who controls the update for each.
For containers, check the base image and the image actually deployed. For managed hosting, check the provider’s runtime policy and rollout status. For a virtual machine, check the executable used by the service, which may differ from the one an interactive terminal finds.
Updating a lockfile alone does not replace the Node runtime. Likewise, rebuilding an application does not guarantee a new runtime if its base image or hosting configuration remains unchanged. It is the same attention to build inputs discussed in Your CI pipeline needs a lockfile too.
Keep the patch small, then test the right paths
Where practical, make the supported patch upgrade a focused change. Combining it with a framework migration or unrelated refactor makes failures harder to explain and rollback decisions harder to make.
Run the normal suite, then exercise the parts that resemble production: uploads, streaming responses, connection cancellation, outbound HTTPS and any client-certificate flows the service actually uses. This is a suggested testing checklist, not a claim that every application needs every test.
Deploy through the usual controlled rollout. Check error rates, restarts and memory behaviour, and record the runtime version from the deployed workload. Keep the rollback plan explicit, including the security implications of returning to the old image.
Check the support horizon too
The release schedule currently lists Node 22 and 24 in Maintenance LTS, with Node 26 in Active LTS. Node’s guidance recommends Active or Maintenance LTS for production applications. A patch is also a useful moment to identify services that have fallen outside that support window. (Release schedule, Node release guidance)
The practical finish line is evidence: the intended runtime reached every relevant workload, important flows still work, and someone owns the next update. A merged version bump is progress. The deployed process is where the protection needs to land.
