---
id: "CVE-2026-123872"
page: "https://infrastack.ai/live/CVE-2026-123872"
kind: "vulnerability"
aliases: ["CVE-2026-123872"]
title: "Node.js TLS: client certificate check bypassed by changing servername during renegotiation"
severity: "high"
cvss: 8.1
epss: null
exploited: false
status: "open"
category: "runtime"
products: [{"name": "node", "fixed": ["22.23.5", "24.22.3", "26.13.1"], "affected": ">= 22.0.0, < 22.23.5 || >= 24.0.0, < 24.22.3 || >= 26.0.0, < 26.13.1", "ecosystem": "vendor"}]
ecosystems: []
tags: ["mutual-tls", "node.js", "runtime", "self-hosted", "tls"]
not_affected_if: ["no-client-certs", "single-policy", "tls-1.3-only"]
published_at: "2026-11-11T19:17:34+00:00"
first_seen_at: "2026-11-11T19:28:45+00:00"
updated_at: "2026-11-11T19:32:09+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-123872", "first_seen_at": "2026-11-11T19:28:45+00:00"}, {"source": "analyst", "url": "https://nodejs.org/en/blog/release/v24.22.3", "first_seen_at": "2026-11-11T19:32:09+00:00", "cites": ["https://nodejs.org/en/blog/release/v24.22.3"]}]
exploit_sources: []
---

# Node.js TLS: client certificate check bypassed by changing servername during renegotiation

Link for people: https://infrastack.ai/live/CVE-2026-123872 (this .md is for agents)

Node.js TLS lets a client switch the servername during a TLS 1.2 renegotiation, so an authenticated connection can reach a host with stricter client-certificate rules. An attacker gets access to endpoints it was not authorized for.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- vendor:node affected >= 22.0.0, < 22.23.5 || >= 24.0.0, < 24.22.3 || >= 26.0.0, < 26.13.1 fixed 22.23.5, 24.22.3, 26.13.1

## How to check

- Run node --version; vulnerable if below 22.23.5 (22.x), 24.22.3 (24.x) or 26.13.1 (26.x).
- Then look for a Node.js TLS server (tls.createServer, https.createServer, server.addContext) that applies different client-certificate policies per hostname (requestCert/rejectUnauthorized, different CA per SNI host). Only TLS 1.2 connections can renegotiate; TLS 1.3 does not support renegotiation.
- Also check CVE-2026-123867 (same release): a per-host client CA set with addContext and no server certificate falls back to the default CA.

## Fix

Upgrade Node.js to 22.23.5 (22.x), 24.22.3 (24.x) or 26.13.1 (26.x). Per the 24.22.3 release notes, the fix stops TLS renegotiation and HelloRetryRequest from changing the SNI, and stops TLS resumption from changing it.

## Timeline

- 2026-11-11T19:28:45+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-123872
- 2026-11-11T19:32:09+00:00 analyst https://nodejs.org/en/blog/release/v24.22.3 — Fixed versions read on the Node.js Nov 11 2026 security release page and 24.22.3 release notes; no exploitation or PoC seen, X/discussion search skipped (low-profile B). Reporter pimterry.

## Documents

- [advisory] Node.js November 11, 2026 Security Releases https://nodejs.org/en/blog/vulnerability/november-2026-security-releases
- [fix] Node.js 24.22.3 (LTS) https://nodejs.org/en/blog/release/v24.22.3

## From the sources

A client certificate authentication bypass in Node.js TLS lets a client change the servername during TLS 1.2 renegotiation to reach endpoints it was not authorized for. On a server that applies different client-certificate policies per hostname, for example stricter admin-only client-cert auth on one host and ordinary client-cert auth on another, a client that authenticates for a permitted host can renegotiate the TLS 1.2 connection under a different servername and carry its existing authentication to the protected host, bypassing the stricter policy. This vulnerability affects Node.js 26.x, 24.x, and 22.x.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_