CVE-2026-30241: Missing Query Depth Validation in Mercurius GraphQL Subscriptions

Mercurius is a popular GraphQL adapter for the Fastify web framework, designed for high performance. To protect against resource exhaustion attacks—common in GraphQL due to the graph-like nature of data—Mercurius provides a queryDepth configuration option. This setting limits the maximum nesting level of incoming queries, preventing clients from requesting exponentially complex data structures.

However, a discrepancy exists in how Mercurius handles different transport protocols. While the HTTP request handler correctly invokes the depth validation logic before execution, the WebSocket handler (used for GraphQL Subscriptions) fails to enforce this check. Consequently, the queryDepth protection is effectively bypassed for any operation submitted via a persistent WebSocket connection.

This vulnerability is classified as CWE-863 (Incorrect Authorization) because the system fails to authorize the resource consumption level (depth) for a specific communication channel, despite the policy being defined globally.

The root cause lies in the architectural separation between HTTP route handling and WebSocket connection management within the Mercurius codebase. Validation logic was not centralized but rather applied independently in each transport handler.

In the HTTP path (lib/routes.js), the request processing pipeline explicitly calls the internal validation utility to check the Abstract Syntax Tree (AST) of the incoming query against the queryDepth limit. If the limit is exceeded, the request is rejected immediately with a 400 error.

In contrast, the WebSocket path is handled by lib/subscription-connection.js. The SubscriptionConnection class manages the lifecycle of WebSocket clients. When a client sends a start (or subscribe) message, the handler parses the payload and initiates the subscription iterator. Prior to version 16.8.0, this flow did not include a call to the queryDepth validator. The parameters for the depth limit were not even passed down to the subscription connection context, making validation impossible within that scope.

The fix required plumbing the queryDepthLimit configuration option down to the SubscriptionConnection class and enforcing the check during the message handling phase.

Vulnerable Code Path (Conceptual): In lib/subscription-connection.js, the message handler simply proceeded to execution:

// Pre-patch logic
handleMessage (message) {
  switch (message.type) {
    case GQL_START:
      // ... parsing logic ...
      this.executeSubscription(id, payload, query, variables, operationName)
      break;
  }
}

Patched Code Path: The commit introduces the validation step explicitly. The queryDepth function is imported and called before execution proceeds.

// lib/subscription-connection.js
 
// [1] Import the validator
const queryDepth = require('./query-depth')
 
// [2] Inside the message handler
if (this.queryDepthLimit) {
  // Validate the parsed document definitions
  const queryDepthErrors = queryDepth(document.definitions, this.queryDepthLimit)
  
  if (queryDepthErrors.length > 0) {
    // [3] Halt execution if depth is exceeded
    const err = new MER_ERR_GQL_VALIDATION()
    err.errors = queryDepthErrors
    this.sendMessage(GQL_ERROR, id, { payload: err })
    return
  }
}

Additionally, index.js and lib/routes.js were updated to ensure queryDepthLimit is passed into the SubscriptionConnection constructor during initialization.

Exploiting this vulnerability requires establishing a WebSocket connection using a standard GraphQL subscription protocol (e.g., graphql-ws or subscriptions-transport-ws). No authentication is strictly required unless the endpoint itself enforces it at the connection level, but the depth check bypass occurs regardless of privilege level.

Attack Scenario:

1. Target Identification: The attacker identifies a GraphQL schema with recursive relationships (e.g., a User type with a friends field that returns a list of User types).
2. Connection: The attacker connects to ws://target.com/graphql.
3. Payload Delivery: The attacker sends a subscription operation with excessive nesting, far exceeding the intended limit (e.g., 100 levels deep).

   subscription { 
     userUpdates { 
       friends { 
         friends { 
           friends { 
             ... # repeated 100+ times
             name 
           } 
         } 
       } 
     } 
   }

4. Trigger: When the subscription event fires (e.g., a user is updated), the server attempts to resolve the graph. Due to the exponential nature of the nested fields, this consumes significant CPU cycles and memory, degrading service for other users.

The primary impact is Denial of Service (DoS). While the CVSS v4.0 score is rated Low (2.7), this likely reflects the specific environmental metrics applied in the context (Availability: Low). In a real-world production environment, uncontrolled recursion can easily crash a Node.js process due to heap allocation failures or block the event loop for extended periods.

Metric Breakdown:

• Confidentiality/Integrity: None. The attacker cannot read unauthorized data or modify data they shouldn't access (assuming field-level authorization works correctly).
• Availability: Low to High. Depending on the schema complexity and server resources, a single malicious subscription could stall the process. If the server automatically restarts, it may lead to a boot-loop if the attacker persists the connection.

This vulnerability is particularly dangerous because subscriptions are long-lived. A successful attack does not require a flood of requests; a single expensive subscription can persistently drain resources every time an event is published.