GHSA-6Q22-G298-GRJH: Unauthenticated Denial of Service via GraphQL Alias Amplification in Directus

Directus exposes a comprehensive GraphQL API to facilitate data querying and system management. The vulnerability exists within the implementation of this GraphQL engine, specifically in how it processes identical resolver requests within a single HTTP payload. Versions prior to 11.17.0 fail to deduplicate these requests, leading to unbounded backend resource consumption.

The flaw is classified as a Denial of Service (DoS) vulnerability triggered by GraphQL alias amplification. The GraphQL specification permits clients to request the same field multiple times within a single query by utilizing different aliases. When an attacker targets a resource-intensive system resolver, the server executes the underlying function for every alias provided in the query structure.

The server_health field is exposed via the system GraphQL endpoint and serves as the primary vector for this vulnerability. Unauthenticated attackers can send a single HTTP request containing thousands of aliases for this specific field. This forces the server to process an equivalent number of concurrent backend infrastructure checks, leading to severe resource exhaustion and service unavailability.

The root cause lies in the absence of request-scoped resolver deduplication within the GraphQL execution pipeline. Standard GraphQL engines invoke the defined resolver function for each field present in the abstract syntax tree (AST) of the query. When aliases are used, the engine treats each alias as a distinct execution path, even if the target field and its arguments are strictly identical.

The server_health resolver in Directus performs a comprehensive suite of backend infrastructure health checks. These checks include validating database connectivity, confirming cache service availability, verifying storage system write permissions, and testing outbound SMTP server connections. Executing this resolver requires substantial I/O operations and blocking network handshakes.

Prior to version 11.17.0, Directus processed these amplified requests linearly without caching the results of identical resolver executions during the lifecycle of the HTTP request. Consequently, an attacker supplying 1,000 aliases for the server_health field forces the application to initiate 1,000 database connections and 1,000 SMTP handshakes simultaneously.

This behavior entirely bypasses standard edge-level rate limiting. The amplification occurs entirely within a single HTTP request boundary, multiplying the server-side processing cost by orders of magnitude while requiring minimal bandwidth from the attacker.

The maintainers addressed this vulnerability in Pull Request #26949 by introducing a dedupeResolver utility. This utility leverages a transient cache stored within the GraphQL context map for the duration of the HTTP request. The fix ensures that repeated calls to the same resolver with identical arguments return the result of the initial execution.

The patch implemented the dedupeResolver function within the dedupe-resolvers.ts file. This function acts as a wrapper around vulnerable resolvers. It generates a unique cacheKey based on the field name, a cryptographic hash of the provided arguments, and the specific selection set, ensuring exact query matching.

export function dedupeResolver(resolver, overrideKey) {
  return (source, args, context, info) => {
    const { cache } = context;
    const cacheKey = overrideKey ?? resolverCacheKey(args, info);
 
    if (!cache.has(cacheKey)) {
      cache.set(cacheKey, resolver(source, args, context, info));
    }
 
    return cache.get(cacheKey);
  };
}

The implementation evaluates whether the cacheKey exists in the request context cache. This cache object is a standard JavaScript Map initialized uniquely for every incoming HTTP request. If the key is absent, the application executes the target resolver and stores the returned Promise object in the map.

Subsequent resolver invocations matching the generated key bypass the expensive execution phase entirely. Instead, the function retrieves and awaits the stored Promise from the context map. This architectural modification reduces the execution complexity of identical aliases from O(N) to O(1), effectively neutralizing the amplification vector.

Exploitation requires no authentication and relies solely on network access to the Directus GraphQL endpoint. The attacker constructs a single HTTP POST request containing a GraphQL query with thousands of aliases referencing the server_health field. The server parses the payload and begins executing the mapped resolver for each alias concurrently.

query {
  h1: server_health
  h2: server_health
  h3: server_health
  h4: server_health
  # Amplified selection sequence repeats
  h1000: server_health
}

Upon receiving this payload, the GraphQL engine initiates the execution phase. For the example query above, the Directus application attempts to allocate 1,000 concurrent database connections from its connection pool. Simultaneously, it initiates 1,000 filesystem write operations and 1,000 outbound network connections to the configured SMTP server.

The immediate result is resource saturation at multiple layers of the application stack. The database connection pool is exhausted, preventing legitimate application queries from executing. Furthermore, the volume of outbound SMTP connection attempts often results in upstream timeouts or temporary IP bans from the configured mail provider.

The vulnerability results in a high-impact Denial of Service condition affecting the primary application and its downstream dependencies. By exhausting the database connection pool, the attack effectively halts all read and write operations for legitimate users interacting with the Directus instance. The service remains functionally unavailable until the malicious query times out or the server process is forcefully terminated.

The severity is reflected in the CVSS v3.1 base score of 7.5. The attack vector is strictly network-based and requires no elevated privileges or user interaction. The execution of the exploit consumes minimal resources on the attacker's side while forcing a disproportionately large resource allocation on the target infrastructure.

Secondary impacts include the potential disruption of shared backend components. The rapid succession of connection attempts to the SMTP server and the underlying database can trigger rate-limiting mechanisms or infrastructure-level denial of service protections. This extends the scope of the service degradation beyond the Directus application container itself.

The authoritative remediation for this vulnerability is upgrading the Directus instance to version 11.17.0 or later. The official patch implements request-scoped deduplication logic, entirely mitigating the alias amplification attack vector. Administrators should prioritize the deployment of this update to all internet-facing instances.

If immediate patching is not operationally feasible, administrators can deploy mitigation rules at the API Gateway or Web Application Firewall (WAF) layer. A structural parsing rule can be implemented to inspect inbound GraphQL JSON payloads and block requests containing an excessive number of aliases or repeated references to the server_health field.

Security teams should also review application telemetry for signatures of active exploitation. Relevant indicators include abrupt spikes in database connection pool utilization, spikes in filesystem write latency, or sudden bursts of outbound network connections on standard SMTP ports. These metrics, when correlating with single large inbound HTTP POST requests to the /graphql/system endpoint, indicate active alias amplification attempts.