CVE-2026-48928

What it actually does

The flaw is an authentication and trust-policy bypass in Node.js TLS hostname matching when applications use multiple TLS or mTLS contexts with different trust rules. Under certain multi-context configurations, Node.js can evaluate hostnames inconsistently, allowing a certificate or peer identity that should only be valid for one context to be treated as acceptable in another. The result is partial loss of confidentiality and integrity: an attacker with some valid credential or access in one trust context may be able to connect to or impersonate a peer in a different context that should have rejected them. Availability is not directly affected.

Why it matters to the business

Organizations using Node.js 22, 24, or 26 for services that rely on mutual TLS, certificate-based service authentication, internal API authentication, or tenant/environment separation may have weaker access boundaries than intended. A successful bypass could let a lower-trust client or service access data or operations reserved for a different trust zone. The CVSS score is moderate, EPSS is currently low, it is not listed in CISA KEV, and no mature public exploit is reported, but the issue affects all supported Node.js release lines and can be significant where mTLS is used as a primary control.

How an attack unfolds

An attacker first obtains a foothold or credential that is legitimately trusted in one TLS context, such as a client certificate, service identity, or account allowed to initiate mTLS connections. They then identify a Node.js application that selects or validates TLS behavior across multiple contexts, such as different virtual hosts, SNI-based TLS contexts, backend service identities, or trust policies. By crafting the connection parameters, hostname, SNI value, certificate identity, or request routing so that Node.js applies inconsistent hostname matching, the attacker attempts to have a certificate accepted outside its intended scope. If the application relies on that mTLS decision for authorization, the attacker can access protected endpoints or impersonate a peer that should have failed certificate or hostname validation. There is no indication from the provided data that this is being actively exploited in the wild, and exploitation is most relevant to applications with complex mTLS trust boundaries rather than ordinary TLS-only clients.

How to fix it

Upgrade Node.js 22, 24, and 26 to vendor-fixed releases as soon as the Node.js project publishes patched versions for this vulnerability. No fixed versions were provided in the input, so teams should track the official Node.js security release announcements and package manager advisories for the exact patched versions. Until patched, reduce exposure by avoiding ambiguous or overlapping TLS contexts, ensuring SNI and expected hostnames are explicitly validated by application code, binding each trust policy to a specific CA/client certificate set, and enforcing authorization checks beyond successful mTLS authentication. Where possible, isolate higher-trust mTLS endpoints from lower-trust clients, disable fallback/default TLS contexts that grant broad trust, and add explicit allowlists for expected certificate subject alternative names, issuers, and service identities.

How to confirm the fix worked

Confirm all affected runtimes are inventoried and determine whether they are Node.js 22, 24, or 26. Verify the installed Node.js version against the official patched versions once published. Review application TLS configuration for use of tls.createSecureContext, SNICallback, https servers with multiple contexts, custom checkServerIdentity logic, client-certificate authentication, and service-to-service mTLS. Test that certificates valid for one context are rejected when used against another context with a different hostname or trust policy. For internet-facing or high-trust services, perform a negative mTLS validation test using a certificate from a lower-trust context and confirm the handshake or application authorization fails. After remediation, repeat these tests and confirm that logs show failed authentication for cross-context certificate use.

Typical attack path

1. Acquire or already possess a low-privilege credential, client certificate, or service identity trusted by at least one mTLS context.
2. Map Node.js services that use multiple TLS contexts, SNI-based context selection, virtual hosts, or per-host trust policies.
3. Craft TLS connection metadata such as hostname, SNI, target host, or certificate identity to trigger inconsistent hostname matching.
4. Establish an mTLS session that should be rejected under the target context but is accepted due to the mismatch.
5. Use the accepted TLS identity to access APIs, data, or service operations protected by certificate-based trust.
6. Blend activity into normal service-to-service traffic because the connection may appear authenticated at the TLS layer.

How to detect it

There is no unique network signature or public exploit artifact provided for this issue, so detection should focus on anomalous successful mTLS authentications and cross-context identity use. Review TLS termination, application, API gateway, reverse proxy, and service-mesh logs for cases where the SNI or requested hostname does not match the authenticated certificate identity, issuer, SAN, or expected service mapping. Look for successful requests from client certificates that are valid for one environment, tenant, service, or trust tier but are accessing endpoints associated with another. Compare historical peer certificate fingerprints and issuers against normal service-to-service baselines. Investigate any recent changes or spikes in TLS authentication failures followed by successful access from the same source, especially where failures mention hostname mismatch, unauthorized certificate, unknown CA, or certificate verification errors. If TLS details are not currently logged, enable logging of peer certificate subject, issuer, SANs, fingerprint, serial number, SNI, requested host, authorizationError, and final authorization decision for affected Node.js services.

What your security team should do

• Prioritize inventory of Node.js 22, 24, and 26 services that use mTLS, SNI-based TLS context selection, or certificate-based service authentication.
• Track official Node.js security releases and upgrade affected runtimes immediately when fixed versions are available.
• Treat mTLS acceptance as authentication only; ensure application-level authorization verifies the expected service, tenant, role, issuer, and certificate identity.
• Review TLS configurations for broad default contexts, overlapping certificate authorities, permissive SNICallback behavior, or custom hostname validation.
• Add negative tests to CI/CD and pre-production validation to ensure certificates from one trust context cannot authenticate to another.
• Increase logging around TLS peer certificate subject, issuer, SAN, fingerprint, SNI, requested hostname, authorization result, and application identity mapping.
• For sensitive services, temporarily segment or restrict access to mTLS endpoints until patched and validated.
• Monitor vendor advisories, EPSS changes, and any future CISA KEV listing or public proof-of-concept activity because exploitation likelihood can change quickly.