CVE-2025-32034: Apollo Router Core DoS Vulnerability

CVE-2025-32034 Overview

CVE-2025-32034 is a denial-of-service vulnerability in the Apollo Router Core, a high-performance graph router written in Rust for federated GraphQL supergraphs using Apollo Federation 2. The flaw resides in the query planning phase, where deeply nested and reused named fragments expand recursively. Each fragment spread triggers a full expansion of its named fragment, producing exponential resource consumption. An unauthenticated attacker can submit a crafted GraphQL query over the network to exhaust CPU and memory on the router. Apollo remediated the issue in apollo-router versions 1.61.2 and 2.1.1. The defect is tracked under [CWE-770: Allocation of Resources Without Limits or Throttling].

Critical Impact

A single unauthenticated GraphQL query containing deeply nested, reused named fragments can exhaust router resources and bring down the federated supergraph endpoint.

Affected Products

• Apollo Router Core versions prior to 1.61.2 (1.x branch)
• Apollo Router Core versions prior to 2.1.1 (2.x branch)
• Federated GraphQL supergraphs deployed on vulnerable Apollo Router builds

Discovery Timeline

• 2025-04-07 - CVE-2025-32034 published to NVD
• 2026-04-15 - Last updated in NVD database

Technical Details for CVE-2025-32034

Vulnerability Analysis

The Apollo Router accepts GraphQL operations and produces an execution plan that delegates work to federated subgraphs. During query planning, the router expands named fragments inline so that the planner can reason about each selection set. The pre-patch implementation expanded a named fragment once for every spread that referenced it, instead of memoizing the expansion. When fragment A spreads fragment B, B spreads fragment C, and each fragment is reused multiple times, the effective selection tree grows exponentially relative to query size.

An attacker submits a small, syntactically valid GraphQL document that triggers this expansion. The router commits CPU and heap memory to materializing the expanded plan before any execution or authorization step that would normally bound work. Repeated requests amplify the impact and stall worker threads, denying service to legitimate clients of the supergraph.

Root Cause

The root cause is the absence of bounded resource accounting during named fragment expansion in the query planner. The planner did not deduplicate expansions for repeated fragment spreads and did not enforce a ceiling on the resulting selection-set size, which maps to [CWE-770].

Attack Vector

Exploitation requires only network access to the router's GraphQL endpoint. No authentication, privileges, or user interaction are needed. The attacker sends a single HTTP POST containing a GraphQL document whose named fragments are deeply nested and reused.

// Patch excerpt: apollo-federation/src/query_graph/build_query_graph.rs
 use crate::query_graph::QueryGraphEdgeTransition;
 use crate::query_graph::QueryGraphNode;
 use crate::query_graph::QueryGraphNodeType;
+use crate::query_plan::query_planning_traversal::non_local_selections_estimation::precompute_non_local_selection_metadata;
 use crate::schema::ValidFederationSchema;
 use crate::schema::field_set::parse_field_set;
 use crate::schema::position::AbstractTypeDefinitionPosition;

Source: Apollo Router commit ab6675a

The patch introduces precompute_non_local_selection_metadata, which estimates and tracks non-local selection costs before the planner performs full expansion. A second helper distinguishes fragments carrying @defer, allowing the planner to handle them safely without redundant traversal:

// Patch excerpt: apollo-federation/src/query_graph/graph_path.rs
+    pub(crate) fn has_defer(&self) -> bool {
+        match self {
+            OpPathElement::Field(_) => false,
+            OpPathElement::InlineFragment(inline_fragment) => {
+                inline_fragment.directives.has("defer")
+            }
+        }
+    }

Source: Apollo Router commit bba032e

Detection Methods for CVE-2025-32034

Indicators of Compromise

• Sustained spikes in apollo-router CPU and resident memory without a matching increase in successful query volume.
• Query planning latency or timeouts climbing into seconds for requests against previously fast operations.
• Inbound GraphQL documents containing many fragment definitions with repeated ...FragmentName spreads nested multiple levels deep.
• HTTP 5xx errors or dropped connections from the router under low external request rates.

Detection Strategies

• Parse GraphQL request bodies at the gateway or WAF and flag documents whose fragment spread count or nesting depth exceeds a configured baseline.
• Correlate router process metrics (CPU, RSS, planner duration) with request IDs to isolate single operations that cause disproportionate resource use.
• Enable structured logging on the router and alert on query_planning spans whose duration exceeds a percentile threshold derived from steady-state traffic.

Monitoring Recommendations

• Export Apollo Router OpenTelemetry metrics for query planning time, parse time, and rejected operations to a central observability backend.
• Monitor subgraph request rates relative to inbound supergraph requests; an exponential mismatch can indicate planner amplification.
• Track router version inventory across environments to confirm all instances run 1.61.2, 2.1.1, or later.

How to Mitigate CVE-2025-32034

Immediate Actions Required

• Upgrade Apollo Router Core to 1.61.2 on the 1.x branch or 2.1.1 on the 2.x branch without delay.
• Place the router behind a rate limiter and a request-size cap to blunt repeated exploitation attempts during the upgrade window.
• Audit recent access logs for unusually large or fragment-heavy GraphQL operations and block offending source addresses.

Patch Information

Apollo released fixes in apollo-router1.61.2 and 2.1.1. The remediation, described in GitHub Security Advisory GHSA-75m2-jhh5-j5g2, changes named fragment handling so expansion cost is precomputed and bounded. Implementation details are visible in commit ab6675a and commit bba032e.

Workarounds

• Enforce operation allow-listing or persisted queries so only pre-approved GraphQL documents reach the router.
• Configure maximum query depth, maximum fragment count, and maximum request body size at an upstream proxy.
• Apply per-client rate limits and concurrency caps to contain the impact of any single abusive caller.

# Pin Apollo Router to a fixed version in a container deployment
docker pull ghcr.io/apollographql/router:v2.1.1

# Verify the running version after rollout
curl -s http://router.internal:4000/health
./router --version  # expect: 2.1.1 or 1.61.2