Improper Certificate Validation Affecting nodejs24 package, versions *


Severity

Recommended
0.0
medium
0
10

Based on Red Hat Enterprise Linux security rating.

Threat Intelligence

EPSS
0.15% (5th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-RHEL10-NODEJS24-22438115
  • published12 Nov 2026
  • disclosed11 Nov 2026

Introduced: 11 Nov 2026

NewCVE-2026-123867  (opens in a new tab)
CWE-295  (opens in a new tab)

How to fix?

There is no fixed version for RHEL:10 nodejs24.

NVD Description

Note: Versions mentioned in the description apply only to the upstream nodejs24 package and not the nodejs24 package as distributed by RHEL. See How to fix? for RHEL:10 relevant fixed versions and status.

A per-host mutual-TLS authorization bypass in Node.js lets a client authorized for the default hostname reach a protected hostname it is not authorized for. When a TLS server assigns a hostname a different client-certificate CA with server.addContext(host, { ca: protectedCA }) but no server certificate in that SNI context, the per-host client CA is never installed and the handshake falls back to the default client CA. In src/crypto/crypto_tls.cc, CertCbDone installs the SNI context's CA only when setSniContext succeeds, but setSniContext returns false for a context with no server certificate, so a CA-only SNI context silently keeps the default CA. A client holding a certificate trusted by the default CA, but not the protected CA, can therefore complete mTLS to the protected hostname and read its response even with requestCert and rejectUnauthorized enabled, while a client certified by the protected CA is rejected. This vulnerability affects Node.js 26.x, 24.x, and 22.x.

CVSS Base Scores

version 3.1