UBUNTU-CVE-2026-123872: Medium severity ubuntu/nodejs vulnerability
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.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to this bypass?
The affected scenario is a Node.js server that uses TLS 1.2 and applies different client-certificate authentication policies by hostname. In particular, a less-privileged hostname must permit a client certificate that would not be authorized for a protected hostname.
What must an attacker be able to do?
The attacker needs a client certificate accepted by a permitted hostname on the same server. They can then renegotiate the TLS 1.2 connection with a different servername and retain the existing authentication when reaching the protected hostname.
Are all Node.js TLS deployments affected?
No. The described bypass depends on per-hostname differences in client-certificate policy and TLS 1.2 renegotiation. Deployments without hostname-specific client-certificate authorization differences do not match the described attack condition.
What can be done if an update cannot be applied immediately?
Avoid relying on hostname-specific client-certificate policies within the same TLS 1.2 server context. Ensure that a certificate accepted for one hostname is not able to grant access to a more protected hostname.
Which Node.js release lines are identified as affected?
Node.js 26.x, 24.x, and 22.x are identified as affected.