CVE-2024-43414

Executive Summary

CVE-2024-43414 is a high-severity denial-of-service (DoS) vulnerability affecting Apollo Federation components, specifically @apollo/query-planner, @apollo/gateway, and the Apollo Router. The flaw resides in the query planner’s candidate permutation calculation logic. When processing a sufficiently complex GraphQL query, especially one involving fields resolvable by multiple subgraphs, the number of possible query plan permutations can exceed JavaScript’s Number.MAX_VALUE. This causes the value to be represented as Infinity, which in turn disables the pruning mechanism for suboptimal plans. The result is an infinite loop of candidate evaluation, leading to unbounded memory consumption and eventual process crash or OOM termination.

The vulnerability is remotely exploitable without authentication, making it a significant threat to any organization using Apollo Federation in production. The attack surface is broad, as any public-facing GraphQL endpoint using the affected versions is potentially vulnerable.

Supply Chain & Package Security

This vulnerability affects the following npm packages:

• @apollo/query-planner (>=2.0.0, <2.8.5)
• @apollo/gateway (>=2.0.0, <2.8.5)
• @apollo/router (Apollo Router, <1.52.1)

Organizations using these packages in their supply chain must immediately audit their dependencies and upgrade to the patched versions. The vulnerability is introduced through the query planner’s core logic, meaning any service that relies on these packages for GraphQL federation is at risk. There is no known workaround that does not involve upgrading or removing the vulnerable condition (shared fields).

CVSS Breakdown & Threat Level

CVSS Score: 7.5 (High) Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

• Attack Vector (AV): Network – The vulnerability can be exploited remotely over the network.
• Attack Complexity (AC): Low – No special conditions or complex steps are required; a crafted query is sufficient.
• Privileges Required (PR): None – No authentication is needed.
• User Interaction (UI): None – The victim does not need to perform any action.
• Scope (S): Unchanged – The exploit does not affect other components.
• Confidentiality (C): None – No data is exposed.
• Integrity (I): None – No data is modified.
• Availability (A): High – The service becomes unavailable due to crash or OOM.

Threat Level: Critical for availability. An attacker can cause a complete denial of service with a single crafted request.

Deep Dive & Mechanics

The Apollo query planner works by breaking an incoming GraphQL query into smaller pieces (fields or fragments). For each piece, it generates a list of candidate execution steps (e.g., which subgraph to query). The total number of possible query plans is the product of the number of candidates for each piece.

Under normal conditions, after generating all candidates, the planner calculates the total permutations and then prunes suboptimal plans to keep the search space manageable. However, when a query involves fields that can be resolved by multiple subgraphs (i.e., shared fields), the number of candidates per piece can be large. In particularly complex queries, the product of these candidate counts can exceed Number.MAX_VALUE (approximately 1.79e308).

In JavaScript, when a number exceeds Number.MAX_VALUE, it becomes Infinity. The pruning logic checks if the count is finite; if it is Infinity, the pruning step is skipped. This causes the planner to evaluate an astronomically large number of plans, effectively entering an infinite loop. The loop consumes all available memory, leading to a crash or OOM kill.

Key Conditions for Exploitation:

1. The supergraph must have at least one field that is resolvable by multiple subgraphs.
2. The query must be sufficiently complex to cause the candidate product to exceed Number.MAX_VALUE.
3. The query planner must be one of the affected versions.

Vulnerable vs. Patched Code

Vulnerable Code (Conceptual):

// In the query planner's candidate evaluation logic
let totalPermutations = 1;
for (const piece of queryPieces) {
    totalPermutations *= piece.candidates.length;
}
// If totalPermutations > Number.MAX_VALUE, it becomes Infinity
if (totalPermutations < MAX_PRUNING_THRESHOLD) {
    // Prune candidates
    pruneCandidates();
}
// If totalPermutations is Infinity, pruning is skipped

Patched Code (Conceptual):

// In the patched version, the product is capped or checked for overflow
let totalPermutations = 1;
for (const piece of queryPieces) {
    totalPermutations *= piece.candidates.length;
    if (!isFinite(totalPermutations) || totalPermutations > MAX_SAFE_PRODUCT) {
        // Force pruning or abort
        totalPermutations = MAX_SAFE_PRODUCT;
        break;
    }
}
// Pruning always occurs
pruneCandidates();

The patch ensures that the product is capped at a safe maximum, preventing Infinity from disabling the pruning mechanism.

Exploitation & Lab Setup

Red Team (Attack Simulation)

Prerequisites:

• A target running Apollo Gateway or Router with a supergraph containing at least one shared field.
• Network access to the GraphQL endpoint.

Exploit Steps:

1. Reconnaissance: Send a simple introspection query to discover the schema. Identify fields that are resolvable by multiple subgraphs (look for @shareable directive in Federation 2 or duplicate field definitions in Federation 1).
2. Craft the Payload: Construct a deeply nested query that repeatedly requests the shared field. The goal is to maximize the number of candidate permutations. Example:

   query {
     sharedField {
       sharedField {
         sharedField {
           # ... repeat many times
         }
       }
     }
   }
   

3. Send the Request: Use a tool like curl or a custom script to send the crafted query to the target endpoint.

   curl -X POST https://target.example.com/graphql \
     -H "Content-Type: application/json" \
     -d '{"query": "query { sharedField { sharedField { ... } } }"}'
   

4. Observe Impact: The target service will become unresponsive, consume all available memory, and eventually crash or be killed by OOM.

Note: No public exploit code is available for this CVE. The above is a conceptual approach.

Blue Team (Defense & Detection)

Immediate Actions:

1. Upgrade all affected packages to the patched versions.
2. Audit schemas to remove @shareable directives or ensure no fields are resolvable by multiple subgraphs.
3. Implement rate limiting on GraphQL endpoints to limit query complexity.
4. Deploy Web Application Firewall (WAF) rules to block deeply nested queries.

Detection:

• Monitor for sudden spikes in memory usage on GraphQL gateway/router processes.
• Alert on logs containing "OOM" or "out of memory" errors.
• Use the detection rules below to identify malicious queries.

Indicators of Compromise (IOCs)

• Memory Exhaustion: Rapid increase in memory usage of the node or router process, leading to OOM kill.
• Process Crash: The GraphQL gateway or router process terminates unexpectedly.
• Log Entries:
  • FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
  • Error: Process exited with code 137 (OOM kill)
• Network Traffic: GraphQL queries with excessive nesting depth (e.g., >10 levels) targeting shared fields.

Detection Engineering

YARA Rule

rule CVE_2024_43414_Apollo_DoS {
    meta:
        description = "Detects potential exploit attempts for CVE-2024-43414 by identifying deeply nested GraphQL queries with shared fields"
        author = "Valters IT"
        date = "2024-10-27"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-43414"
    strings:
        $shared_field = /sharedField|@shareable/i
        $nested_query = /(\{.*?){10,}/  // 10 or more nested braces
    condition:
        $shared_field and $nested_query
}

Sigma Rule

title: CVE-2024-43414 - Apollo Federation DoS via Complex Query
id: 8a4b3c2d-1e5f-4a7b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects GraphQL queries with excessive nesting that may trigger the Apollo query planner infinite loop vulnerability.
author: Valters IT
date: 2024-10-27
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem: '/graphql'
        cs-uri-query|contains: 'query'
    condition: selection
    # Additional analysis required to check for deep nesting in the request body
fields:
    - c-ip
    - cs-uri-query
falsepositives:
    - Legitimate complex queries from internal tools
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-43414 - Apollo Federation DoS Attempt"; flow:to_server,established; content:"POST"; http_method; content:"/graphql"; http_uri; content:"query"; http_client_body; pcre:"/(\{.*?){10,}/"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Remediation:

1. Upgrade @apollo/query-planner to v2.8.5 or later.
2. Upgrade @apollo/gateway to v2.8.5 or later.
3. Upgrade Apollo Router to v1.52.1 or later.

Mitigation (if upgrade is not immediately possible):

• Remove all @shareable directives from Federation 2 subgraph schemas.
• For Federation 1, ensure no fields are resolvable by multiple subgraphs.
• Implement query depth limiting (e.g., max depth of 5) using middleware or API gateway features.
• Deploy a WAF with rules to block queries with excessive nesting.

Long-Term Prevention:

• Regularly audit GraphQL schemas for shared fields.
• Implement resource limits (memory, CPU) on GraphQL processes.
• Use container orchestration (e.g., Kubernetes) with resource quotas and auto-scaling to mitigate DoS impact.

Valters IT
Securing the Digital Frontier