CVE-2026-48930

What it actually does

Node.js TLS and resolver hostname handling can mishandle hostnames containing embedded NUL bytes. Because some native resolver bindings treat hostnames as C strings, a hostname may be truncated at the first NUL byte while higher-level JavaScript or TLS logic may operate on a different logical hostname. This can create silent authority rebinding: an application believes it is validating, connecting to, or authorizing one hostname while the underlying resolution or TLS connection is performed against another. In affected Node.js 22, 24, and 26 applications, the flaw can undermine hostname validation, allowlist checks, outbound request controls, TLS peer identity assumptions, and service-to-service trust boundaries when attacker-controlled hostnames or URLs are passed into Node.js networking/TLS APIs.

Why it matters to the business

Applications that accept URLs or hostnames from users, partners, webhooks, configuration, API parameters, redirects, or metadata sources may be tricked into connecting to unintended destinations while appearing to connect to trusted ones. This can lead to data exposure, unauthorized internal network access, bypass of egress restrictions, credential/token leakage to attacker-controlled infrastructure, request forgery, or disruption of critical integrations. The CVSS severity is critical, but exploitation depends on whether an application passes attacker-influenced hostnames into affected Node.js TLS or resolver paths. The issue affects all supported Node.js release lines listed in the advisory, so remediation may require broad runtime inventory and coordinated application rebuilds or redeployments.

How an attack unfolds

An attacker first identifies a Node.js application feature that accepts a hostname or URL and causes the server to make an outbound TLS connection, such as webhook delivery, URL previewing, import-from-URL, OAuth/OIDC metadata retrieval, package fetching, proxying, federation, or integration callbacks. The attacker supplies a crafted hostname containing an embedded NUL byte so that different layers interpret the authority differently. Application-layer validation may see the full hostname and decide it is acceptable, or TLS and resolver components may disagree about the hostname being verified versus the hostname being resolved. Due to C-string truncation in the native resolver path, the actual lookup or connection target can be rebound to the substring before the NUL byte. If the application relies on hostname allowlists, certificate identity, or domain-based routing for security, the attacker can use this mismatch to reach a host that should not have been reachable, cause credentials or bearer tokens to be sent to an unintended endpoint, access internal resources through server-side request forgery, or interfere with trusted service communications. There is no public exploitation maturity reported and the issue is not listed in CISA KEV, but its low attack complexity and network attack surface make exposed URL/hostname ingestion paths high priority to review.

How to fix it

Upgrade affected Node.js runtimes to the vendor-provided patched releases for each supported line as soon as they are available for Node.js 22, 24, and 26. Because exact fixed versions were not provided in the input, track the official Node.js security release advisory for CVE-2026-48930 and standardize builds on the first patched or later release for the deployed major line. Rebuild and redeploy containers, serverless runtimes, base images, CI images, and packaged desktop/server applications that embed Node.js. As defense in depth, reject hostnames and URLs containing NUL bytes or encoded NUL representations before they reach networking APIs; canonicalize URLs with a strict parser; enforce allowlists after canonicalization; compare the canonical hostname used for validation with the hostname used for resolution and TLS verification; avoid passing untrusted hostnames directly into DNS, TLS, HTTPS, proxy, or redirect-following code; and enforce egress controls at the network layer so application-layer hostname confusion cannot reach sensitive internal services. If immediate runtime upgrade is not possible, add input validation that blocks raw NUL characters and common encodings such as %00, \x00, and \u0000 in all URL/hostname ingestion paths, and disable or restrict features that fetch attacker-supplied URLs.

How to confirm the fix worked

Confirm the deployed Node.js runtime version for every application, container image, build image, serverless runtime, and embedded distribution, then verify it is a patched release for the relevant Node.js 22, 24, or 26 line once vendor fixed versions are published. Review dependency and container manifests for inherited Node.js base images. Add automated tests that pass hostnames and URLs containing embedded NUL representations into any URL ingestion, webhook, proxy, redirect, federation, import, or metadata-fetching workflow and assert that the input is rejected before DNS or TLS activity occurs. Validate that application logs, outbound proxy logs, DNS logs, and TLS telemetry show no attempted resolution or connection for NUL-containing hostnames. For compensating controls, test that network egress policies block access to internal metadata services, loopback, private address ranges, and sensitive internal domains from application workloads that process untrusted URLs.

Typical attack path

1. Find a Node.js 22, 24, or 26 application feature that accepts a user-controlled URL or hostname and performs DNS, HTTPS, TLS, proxy, or service-discovery operations.
2. Craft a hostname containing an embedded NUL byte using a raw NUL, percent encoding, Unicode escape representation, or another encoding that survives application parsing.
3. Submit the crafted hostname through a web request, API parameter, webhook configuration, integration setting, redirect target, or metadata document consumed by the application.
4. Trigger the application to validate or authorize one logical hostname while Node.js native resolver/TLS handling truncates or interprets the hostname differently.
5. Cause the application to connect to an unintended authority, bypass domain restrictions, or leak outbound credentials, headers, tokens, or data.
6. Use the resulting connection confusion to perform SSRF, internal service access, trusted-domain bypass, data exfiltration, or denial of service depending on the application workflow.

How to detect it

To determine whether exploitation was already attempted, review logs from components that capture user-supplied URLs and hostnames: application access logs, API gateway logs, reverse proxy logs, WAF logs, webhook/integration configuration audit logs, outbound proxy logs, DNS resolver logs, TLS/SNI telemetry, EDR network events, and cloud flow logs. Look for raw or encoded NUL-byte patterns in URL, hostname, callback, redirect_uri, webhook, target, endpoint, proxy, Host, authority, and SNI fields. Because some logging systems truncate at a NUL byte or normalize control characters, also look for mismatches where the recorded application-level destination differs from DNS queries, outbound proxy CONNECT targets, or TLS SNI/certificate names around the same timestamp. Investigate outbound requests from Node.js services to unexpected public domains, private IP ranges, loopback addresses, link-local metadata addresses, or internal service names following requests that supplied externally controlled URLs. Correlate suspicious requests with credential use: Authorization headers, API keys, OAuth tokens, service tokens, signed URLs, cookies, or mTLS client certificates sent to unusual destinations. If evidence of successful rebinding exists, preserve request bodies and configuration changes, collect DNS/proxy/TLS telemetry for the affected time window, identify any secrets transmitted, rotate exposed credentials, and review target-side logs for follow-on access.

• %00
• \x00
• \u0000
• %2500
• %0000
• 0x00
• NUL
• \0
• Host: *%00*
• CONNECT *%00*
• SNI=*%00*
• redirect_uri=*%00*
• callback_url=*%00*
• webhook_url=*%00*
• url=*%00*
• target=*%00*
• endpoint=*%00*
• hostname=*%00*
• http://*%00*
• https://*%00*

What your security team should do

• Inventory all production and build-time uses of Node.js 22, 24, and 26, including containers, serverless runtimes, CI images, bundled applications, and developer tooling used to package production artifacts.
• Prioritize internet-facing or externally integrated Node.js services that accept URLs, hostnames, redirects, webhook targets, federation endpoints, import locations, or metadata documents from untrusted parties.
• Track the official Node.js security release and upgrade each affected major line to the first fixed version or later; rebuild and redeploy images rather than only patching host-level packages.
• Immediately add centralized validation to reject raw and encoded NUL bytes in URL and hostname inputs before they reach Node.js DNS, HTTPS, TLS, fetch, proxy, or redirect-following code.
• Review allowlist and SSRF protections to ensure checks are performed on a canonical hostname and reinforced with DNS/IP range validation and network egress controls.
• Search historical logs for NUL-byte encodings in URL, Host, SNI, webhook, callback, redirect, and integration fields to identify possible probing or exploitation attempts.
• Increase monitoring for unexpected outbound TLS connections, DNS lookups, or credential-bearing requests from Node.js services to newly observed domains or IPs.
• If sensitive tokens or headers may have been sent during suspicious outbound requests, rotate exposed credentials and review downstream access logs.