CVE-2026-48618

What it actually does

The flaw is a TLS hostname verification inconsistency in Node.js. Certain Unicode dot separator characters can be normalized differently by name resolution and certificate verification logic. Under affected configurations, this can cause wildcard certificate depth checks to be applied to a hostname representation that differs from the hostname actually being resolved or contacted. The result is a TLS authentication bypass where a certificate that should not validate for a target hostname may be accepted. The primary technical impact is confidentiality loss, such as an attacker being able to impersonate a TLS endpoint or intercept traffic when they can influence the destination hostname, certificate, DNS path, proxy path, or network position used by a vulnerable Node.js application.

Why it matters to the business

Applications built on affected Node.js 22, 24, or 26 releases may trust the wrong TLS certificate for outbound HTTPS or TLS connections. In practical terms, sensitive data sent to external services, APIs, webhooks, package sources, identity providers, or internal service endpoints could be exposed to an attacker in scenarios where hostnames are attacker-influenced or traffic can be intercepted. The issue is not currently listed in CISA KEV and no public exploit maturity is reported, but it has been public for 46 days and affects all supported Node.js release lines, so organizations with broad Node.js usage should treat patching as a priority for internet-facing, integration-heavy, or high-trust service-to-service workloads.

How an attack unfolds

An attacker first identifies a Node.js application that makes TLS or HTTPS connections to hostnames influenced by user input, partner configuration, webhook destinations, federation metadata, package or plugin sources, redirects, proxy configuration, or service discovery. The attacker supplies or causes use of a hostname containing Unicode dot separator characters such as ideographic full stop, fullwidth full stop, or halfwidth ideographic full stop. Because the resolver and TLS verifier do not normalize that hostname identically, the hostname used for wildcard-depth certificate validation can differ from the effective resolved name. The attacker then presents or routes the connection to a server using a wildcard certificate that would normally be rejected for the intended hostname depth. The vulnerable Node.js runtime may accept the certificate, allowing the attacker-controlled endpoint to be treated as authentic. If the application sends credentials, tokens, session cookies, API keys, request bodies, or confidential data over that connection, the attacker can capture that data or observe sensitive transactions without needing to break TLS cryptography itself.

How to fix it

Upgrade affected Node.js runtimes in the 22, 24, and 26 release lines to vendor-provided patched versions as soon as they are available through official Node.js security releases or trusted distribution packages. Because no exact fixed versions were provided in the input, track the official Node.js advisory and distribution-specific errata, then standardize on the patched build for each supported release line in use. Rebuild and redeploy containers, serverless runtimes, CI images, developer workstations, and base images that bundle Node.js. As defense in depth, avoid passing untrusted hostnames directly into TLS or HTTPS clients; normalize and validate hostnames using a single, strict canonicalization path; reject Unicode dot separator characters in security-sensitive hostnames unless explicitly required; enforce allowlists for outbound destinations; pin expected service identities where practical; and avoid relying solely on wildcard certificates for high-trust service boundaries.

How to confirm the fix worked

Inventory Node.js versions across hosts, containers, build images, CI runners, and application runtimes and confirm that affected 22.x, 24.x, and 26.x builds have been replaced with patched security releases once published by the vendor or distribution. Validate running versions with commands such as `node --version` and by inspecting container manifests and package manager metadata. For application-level validation, test representative outbound TLS and HTTPS code paths with hostnames containing Unicode dot separators and confirm that certificates outside the intended hostname scope are rejected. Review dependency and base-image scans to ensure no vulnerable Node.js runtime remains embedded in production artifacts. Confirm that outbound URL validation rejects or canonicalizes Unicode dot separators consistently before DNS resolution and TLS verification.

Typical attack path

1. Find a Node.js application on an affected release line that initiates outbound HTTPS or TLS connections.
2. Identify a feature where the destination hostname can be influenced, such as webhooks, redirects, integrations, federation, plugins, package retrieval, proxying, or user-supplied URLs.
3. Craft a hostname using Unicode dot separator characters that creates a mismatch between resolver normalization and TLS hostname verification.
4. Arrange DNS, routing, or an attacker-controlled endpoint so the vulnerable application connects to infrastructure controlled or observed by the attacker.
5. Present a wildcard TLS certificate that should not be valid for the intended hostname depth but may be accepted because of the normalization mismatch.
6. Receive the TLS connection as a trusted endpoint and collect any secrets, credentials, tokens, or sensitive payloads transmitted by the Node.js application.

How to detect it

This vulnerability is difficult to confirm from endpoint logs alone because successful exploitation may look like a normal outbound TLS connection. Focus on evidence of suspicious hostname input and outbound connections. Review application logs, API gateway logs, reverse proxy logs, egress proxy logs, DNS resolver logs, TLS inspection logs, cloud flow logs, and webhook or integration audit logs for hostnames containing Unicode dot separator characters. Pay special attention to fields containing URLs, callback URLs, redirect targets, webhook endpoints, federation metadata, package registry URLs, plugin sources, and proxy destinations. Investigate cases where a Unicode-dot hostname was accepted and followed by outbound HTTPS/TLS traffic, especially if credentials, tokens, or sensitive payloads were transmitted. Compare TLS certificate subject alternative names and wildcard depth against the intended logical hostname; a connection using a wildcard certificate that should not match the intended hostname is suspicious. If available, inspect application traces for Node.js HTTPS/TLS client calls where the original hostname differs from the canonicalized DNS name or SNI value. Because there are no known public exploit artifacts or KEV-listed campaigns, treat the listed indicators as hunt signals rather than proof of compromise.

• \u3002
• \uFF0E
• \uFF61
• 。
• ．
• ｡
• [\u3002\uFF0E\uFF61]
• https://*.。
• https://*.．
• https://*.｡
• servername contains Unicode dot separator
• hostname contains Unicode dot separator
• URL contains Unicode dot separator

What your security team should do

• Prioritize patch planning for all Node.js 22, 24, and 26 deployments, especially services that make outbound HTTPS/TLS requests to user-configurable or partner-controlled destinations.
• Create an inventory of applications that accept URLs, hostnames, webhook targets, package sources, plugin repositories, federation endpoints, redirects, or proxy destinations and run on affected Node.js versions.
• Until patched runtimes are deployed, block or reject hostnames containing Unicode dot separators in security-sensitive outbound connection paths.
• Add outbound destination allowlists for high-value integrations and service-to-service communication where feasible.
• Rebuild base images and redeploy containers rather than only patching host-level Node.js packages.
• Search historical proxy, DNS, application, and TLS telemetry for Unicode dot separator usage in hostnames and investigate any connections that carried sensitive data.
• Review whether secrets, tokens, API keys, or credentials could have been sent to attacker-influenced outbound destinations and rotate exposed credentials if suspicious activity is found.
• Monitor official Node.js security release notes and operating system distribution advisories for exact fixed versions and emergency update instructions.