CVE-2026-103921: TLS Certificate Validation Bypass in @graphql-tools/executor-legacy-ws

The @graphql-tools/executor-legacy-ws package is a utility within the graphql-tools ecosystem designed to manage legacy WebSocket connection transports. Specifically, the buildWSLegacyExecutor() function sets up WebSocket endpoints using the older graphql-ws sub-protocol. When initiating a secure outbound WebSocket connection over wss:// within a Node.js runtime environment, the executor is responsible for establishing a cryptographically secure transport layer.

Prior to version 1.1.35, the package contained an architectural flaw where the TLS configuration parameter rejectUnauthorized was hardcoded to false. This parameter controls whether Node.js rejects connections from servers that present invalid, untrusted, or self-signed TLS certificates. Because this verification check was explicitly bypassed, the application failed to establish identity assurance for any remote WebSocket server.

This vulnerability is classified under CWE-295 (Improper Certificate Validation). The attack surface resides primarily in server-side JavaScript applications, backend microservices, or GraphQL gateways that communicate with remote GraphQL APIs over secure WebSockets. Clients executing within native web browsers are unaffected by this vulnerability, as web browsers ignore Node.js-specific WebSocket configurations and strictly enforce system-level certificate validation rules.

The root cause of this vulnerability lies in the implementation of the buildWSLegacyExecutor function within packages/executors/legacy-ws/src/index.ts. When establishing a connection, the function instantiates a WebSocket client using a runtime-defined implementation, typically the ws package in Node.js. During this initialization, configuration parameters are passed to define transport-layer behaviors.

The codebase hardcoded the TLS options inside the constructor arguments. By setting rejectUnauthorized: false, the executor instructed the Node.js tls and https modules to bypass the validation of the peer certificate chain. This bypass disabled critical validation steps, including verifying that the certificate was signed by a trusted root Certificate Authority (CA), checking the expiration date of the certificate, and ensuring that the Common Name (CN) or Subject Alternative Name (SAN) of the certificate matched the destination hostname.

Consequently, the TLS socket failed open, accepting any X.509 certificate presented during the cryptographic handshake. An attacker capable of intercepting traffic at the network routing or DNS resolution layer could easily establish a TLS session using a self-signed or domain-mismatched certificate. The Node.js application would establish the WebSocket tunnel without throwing any warnings or connection errors, completely undermining the confidentiality and integrity assurances of the wss:// scheme.

An analysis of the fix implemented in Pull Request #8426 (commit 3831a0661514c91d99971052f983552556880402) demonstrates the transition to a secure-by-default posture. The vulnerable implementation in packages/executors/legacy-ws/src/index.ts had hardcoded options:

// Vulnerable Code
websocket = new WebSocketImpl(subscriptionsEndpoint, 'graphql-ws', {
  followRedirects: true,
  headers: options?.headers,
  rejectUnauthorized: false, // <-- Hardcoded bypass
  skipUTF8Validation: true,
});

The security patch introduced an explicit interface option rejectUnauthorized to both LegacyWSExecutorOpts and LoadFromUrlOptions. The default value is resolved using the nullish coalescing operator (?? true), ensuring that if the developer does not configure this option, it defaults securely to true:

// Patched Code
websocket = new WebSocketImpl(subscriptionsEndpoint, 'graphql-ws', {
  followRedirects: true,
  headers: options?.headers,
  rejectUnauthorized: options?.rejectUnauthorized ?? true, // <-- Secure default
  skipUTF8Validation: true,
});

This remediation ensures that Node.js validates the entire certificate chain against its list of trusted root authorities. The patch is cryptographically complete; it restores native validation rules by default while preserving functionality for developers who must explicitly disable validation when testing against local, self-signed mock environments.

To exploit this vulnerability, an attacker must position themselves on the network path between the vulnerable Node.js client application and the target GraphQL WebSocket server. This can be achieved through techniques such as local network ARP poisoning, DNS spoofing, or router compromising. The attacker does not need prior authentication to execute this attack.

Once positioned, the execution proceeds as follows:

During step 2, the attacker's gateway presents an arbitrary, self-signed certificate. Because of the vulnerability, the client skips certificate validation and establishes a secure-looking connection. During step 5, the client transmits subscription payloads, which routinely carry highly sensitive parameters inside HTTP headers or the connectionParams configuration object, such as authorization bearer tokens or user session identifiers. The attacker decrypts this outbound communication, extracts the secrets, and gains full access to downstream data feeds.

The security impact of CVE-2026-103921 is significant for enterprise backends that rely on real-time subscriptions. The CVSS base score of 7.4 reflects a high-severity threat. Since the attacker must establish an Adversary-in-the-Middle position, the Attack Complexity (AC) metric is rated as High. However, no privileges (PR:N) or user interactions (UI:N) are required to complete the exploitation.

Successful exploitation results in a complete loss of confidentiality and integrity for the affected WebSocket channel. Because WebSockets are designed for bidirectional, long-lived communications, attackers can not only harvest static credentials but also manipulate incoming message feeds. In systems tracking financial data, system events, or industrial monitoring, the injection of malicious data packets into the application flow could trigger secondary, critical logic failures.

The scope is limited to systems operating in server-side environments where JavaScript packages directly negotiate raw TLS streams. Desktop client applications developed with frameworks like Electron may also be affected if they employ these tools inside their background Node processes.

Remediation requires upgrading the underlying dependencies of the graphql-tools ecosystem. Developers should upgrade @graphql-tools/executor-legacy-ws to version 1.1.35 or higher. Applications that consume this executor transitively through @graphql-tools/url-loader must upgrade that package to version 9.1.8 or higher, which forces resolution of the patched executor.

In scenarios where third-party APIs use self-signed certificates in isolated, internal Virtual Private Clouds (VPCs), developers should avoid global environment overrides such as NODE_TLS_REJECT_UNAUTHORIZED=0, as this disables security globally. Instead, use the newly introduced rejectUnauthorized configuration property to surgically override validation checks only in local development environments.

Additionally, implementing active security monitoring at the network layer, such as deploying Intrusion Detection Systems (IDS) that flag unexpected TLS handshakes or unauthorized certificate changes, will help detect unauthorized MitM attempts.