Summary
GraphQL Tools can disable TLS certificate verification for legacy WebSocket connections to wss:// endpoints. When an application uses the affected executor directly or relies on the legacy WebSocket subscription protocol, a network-positioned attacker may intercept the connection, disclose authentication material, or alter subscription data.
Affected context
The issue occurs in applications using GraphQL Tools' legacy WebSocket executor for secure WebSocket connections. It becomes risky when certificate validation is disabled and an attacker can position themselves between the application and the intended wss:// service. Browser-based WebSocket clients are generally not affected because browsers enforce certificate validation independently.
Exploit preconditions
- Attack surface: Node.js connections created through the legacy WebSocket executor or compatible URL-loading paths
- Required access: Network positioning sufficient to intercept or interfere with the TLS connection
- Trigger point: Establishment of a legacy WebSocket connection to a
wss://endpoint - Why exploitation is possible: The client does not properly reject an untrusted server certificate, allowing an intercepted connection to appear valid to the application
Why this happens
The underlying bug is improper certificate validation, mapped to CWE-295. The legacy WebSocket connection logic hardcodes TLS certificate rejection off, causing the client to accept certificates that should fail trust or hostname verification. This weakens the authentication property of TLS and permits an intermediary to impersonate the intended endpoint.
Potential impact
- Authentication tokens or other connection parameters may be disclosed
- Request headers containing sensitive credentials could be exposed
- Subscription messages or returned data could be modified
- An attacker could impersonate the GraphQL service
- Application behavior or downstream data processing could be influenced
General mitigation guidance
Mitigation should center on preserving end-to-end TLS certificate validation for all secure WebSocket connections.
Common defensive patterns include:
- Use WebSocket clients and connection options that verify certificates by default
- Avoid disabling certificate rejection or hostname verification in production
- Prefer maintained subscription protocols with secure, standards-based transport behavior
- Reduce the sensitivity and lifetime of credentials placed in connection parameters or headers
- Apply least privilege to tokens used by GraphQL clients
- Use network controls that limit unauthorized interception and endpoint substitution
- Ensure secure transport settings cannot be overridden by untrusted configuration
How teams detect issues like this
Organizations can detect this class of issue through:
- Static analysis for disabled certificate verification, insecure TLS options, or certificate-rejection overrides
- Code review checks covering WebSocket client construction and transport configuration
- Dependency and configuration policies that prohibit insecure TLS settings in production
- Integration tests that verify invalid, expired, and hostname-mismatched certificates are rejected
- Network monitoring for unexpected WebSocket destinations, certificate changes, or TLS interception indicators
Automated dependency and code review tools may help identify affected usage patterns and insecure transport configuration.
