Published November 12, 2026. Security releases dated November 11 are available for Node.js 22, 24 and 26: 22.23.5, 24.22.3 and 26.13.1. These are shipped updates, not an advance patch notice. The release notes include fixes for HTTP/2 memory safety and availability, HTTPS handling and TLS policy enforcement.
Why certificate policy needs a regression test
The official advisory identifies three trust-boundary problems: TLS 1.2 renegotiation can carry client authentication to a different hostname (CVE-2026-123872, High); a CA-only SNI context can retain the default client CA (CVE-2026-123867, Medium); and an https.Agent cache collision can reuse a session across omitted ca and ca: [] policies (CVE-2026-123877, Medium). The advisory lists all three supported branches as affected by these issues. Exposure depends on the configuration; this is not a claim that every Node.js application accepts unauthorized clients.
A practical rollout, not just a version check
The following is our operational checklist, not a vendor workaround:
- Find the running copy. Inventory application containers, background workers, build agents and bundled runtimes. A developer laptop reporting the new version does not establish what production is executing. Record the runtime version from the actual workload and identify its package or image owner.
- Patch within the supported branch. Use the relevant official release or a distributor package with documented equivalent fixes. Rebuild and redeploy images rather than only changing a Dockerfile. Confirm that replacement processes started with the patched runtime. An application dependency update alone is not evidence of a runtime update.
- Test both acceptance and rejection. In staging, use synthetic certificates and data. For each protected hostname, record which client CA should be accepted, which should be rejected and what an unauthenticated request should do. Exercise fresh and resumed sessions. Include the outbound clients that deliberately override default trust. A successful happy-path handshake is only half the test.
- Watch behavior after deployment. Compare TLS failures, authentication denials, HTTP/2 disconnects and memory use against the pre-change baseline. If a legitimate integration fails, investigate its intended policy rather than disabling certificate verification to make the alert disappear.
What counts as completion
Keep one concise deployment record: workload owner, running version or vendor patch reference, replacement time, expected certificate-policy results and the observed results. For managed runtimes, request the provider's rollout status instead of assuming its update schedule matches upstream.
A patch release is not proof that a particular system was attacked. Equally, a clean error dashboard is not proof that an old runtime is safe. The useful outcome is a patched process plus evidence that the application's intended trust boundaries still hold.