CVE-2026-48618

Overview

Node.js is a JavaScript runtime built on Chrome's V8 JavaScript engine. It uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, and it is widely used for web applications and server-side development.

A hostname-normalization mismatch between Node.js's resolver and its TLS certificate verifier (CVE-2026-48618) can lead to a TLS wildcard-depth authentication bypass. Node.js's hostname resolution treats certain Unicode characters as equivalent to the ASCII "." (dot) label separator, but the certificate verifier that later checks the connection's hostname against a certificate's wildcard entries does not apply the same normalization. An attacker who controls a hostname value processed by both components can exploit this mismatch to have a certificate validated at a different wildcard depth than it was actually issued for, bypassing the boundary wildcard-depth matching exists to enforce and undermining the confidentiality and identity guarantees TLS is meant to provide.

Per CWE-289 (Authentication Bypass by Alternate Name), this class of flaw arises when a security check is performed using one representation of an identity (here, a hostname) while enforcement or an attacker-controlled comparison uses a different, inconsistently normalized representation of that same identity.

Node.js's own advisory scopes this issue to the currently supported Node.js 22, 24, and 26 release lines. HeroDevs' NES release notes independently corroborate a broader fix: NES also shipped fixes for this CVE on the Node.js 12, 14, 16, 18, and 20 End-of-Life lines, all dated June 25, 2026. This is deliberate NES coverage of EOL lines that Node.js's own advisory does not scope to, not a documentation error.

Details

Module Info

• Product: Node.js
• Affected packages: node (the vulnerability is in Node.js's own TLS/hostname-matching code, not a bundled third-party dependency)
• Affected versions: <=22.22.3; <=24.16.0; <=26.3.0 (per upstream advisory/NVD/CNA scope; HeroDevs' NES additionally covers the Node.js 12, 14, 16, 18, and 20 End-of-Life lines as deliberate EOL security coverage, even though Node.js's own advisory does not scope its affected-versions list to those lines)
• GitHub repository: https://github.com/nodejs/node
• Published packages: https://nodejs.org/en/download
• Package manager: Not applicable. Node.js is distributed as runtime builds from nodejs.org rather than as a published npm package.
• Fixed in: NES for Node.js v12.22.19, v14.21.12, v16.20.13, v18.20.18, and v20.20.3 (all June 25, 2026); upstream Node.js 22.23.0, 24.17.0, and 26.3.1 (June 18, 2026)

Vulnerability Info

This vulnerability is rated Medium (CVSS v3.1 6.5, per NVD) and is found in Node.js's TLS module, in the interaction between hostname resolution and certificate hostname verification. Note: the CNA (HackerOne), Red Hat's ADP, and Node.js's own security advisory all independently rate this CVSS v3.0 7.7, High.

TLS wildcard certificates (for example, a certificate for *.example.com) are only supposed to validate for hostnames at the specific subdomain depth the wildcard covers; a certificate for *.example.com should not validate for a.b.example.com. This boundary depends on both the resolver and the verifier agreeing on how a hostname is split into labels.

Because Node.js's resolver and its certificate verifier disagree about whether certain Unicode characters count as a label (dot) separator, a crafted hostname can be resolved as one set of labels but verified as a different set, letting a certificate that should only match a narrower wildcard depth validate against a broader one (or vice versa). This is distinct from, but related to, CWE-176 (Improper Handling of Unicode Encoding), which the CNA also cited for the underlying normalization defect.

Note: exploitation requires the attacker to control or influence a hostname value that both Node.js components process (for example, one derived from user input or an attacker-controlled certificate/DNS response); it is not a blanket bypass of all TLS wildcard checking.

Mitigation

Officially, this issue affects the currently supported Node.js 22, 24, and 26 release lines, per Node.js's own advisory, all of which have patched releases available (22.23.0, 24.17.0, 26.3.1).

Node.js 12 reached End-of-Life on April 30, 2022; Node.js 14 reached End-of-Life on April 30, 2023; Node.js 16 reached End-of-Life on September 11, 2023; Node.js 18 reached End-of-Life on April 30, 2025; and Node.js 20 reached End-of-Life on April 30, 2026. For more information see here. HeroDevs' NES delivered post-EOL security fixes for this CVE on all five End-of-Life lines (v12.22.19, v14.21.12, v16.20.13, v18.20.18, and v20.20.3), all released June 25, 2026, even though Node.js's own advisory does not name these lines as affected.

Users of the affected components should apply one of the following mitigations:

• Upgrade to a supported Node.js release (22.23.0, 24.17.0, 26.3.1, or later).
• Migrate affected applications away from the End-of-Life Node.js release line(s).
• Leverage a commercial support partner like HeroDevs for post-EOL security support, through NES for Node.js.

Credits

• tmeletlidis (reporter)
• Matteo Collina (remediation developer)