High severityNVD Advisory· Published Aug 27, 2024· Updated Aug 27, 2024

Apollo Query Planner and Apollo Gateway may infinitely loop on sufficiently complex queries

CVE-2024-43414

Description

Apollo Federation is an architecture for declaratively composing APIs into a unified graph. Each team can own their slice of the graph independently, empowering them to deliver autonomously and incrementally. Instances of @apollo/query-planner >=2.0.0 and <2.8.5 are impacted by a denial-of-service vulnerability. @apollo/gateway versions >=2.0.0 and < 2.8.5 and Apollo Router <1.52.1 are also impacted through their use of @apollo/query-panner. If @apollo/query-planner is asked to plan a sufficiently complex query, it may loop infinitely and never complete. This results in unbounded memory consumption and either a crash or out-of-memory (OOM) termination. This issue can be triggered if you have at least one non-@key field that can be resolved by multiple subgraphs. To identify these shared fields, the schema for each subgraph must be reviewed. The mechanism to identify shared fields varies based on the version of Federation your subgraphs are using. You can check if your subgraphs are using Federation 1 or Federation 2 by reviewing their schemas. Federation 2 subgraph schemas will contain a @link directive referencing the version of Federation being used while Federation 1 subgraphs will not. For example, in a Federation 2 subgraph, you will find a line like @link(url: "https://specs.apollo.dev/federation/v2.0"). If a similar @link directive is not present in your subgraph schema, it is using Federation 1. Note that a supergraph can contain a mix of Federation 1 and Federation 2 subgraphs. This issue results from the Apollo query planner attempting to use a Number exceeding Javascript’s Number.MAX_VALUE in some cases. In Javascript, Number.MAX_VALUE is (2^1024 - 2^971). When the query planner receives an inbound graphql request, it breaks the query into pieces and for each piece, generates a list of potential execution steps to solve the piece. These candidates represent the steps that the query planner will take to satisfy the pieces of the larger query. As part of normal operations, the query planner requires and calculates the number of possible query plans for the total query. That is, it needs the product of the number of query plan candidates for each piece of the query. Under normal circumstances, after generating all query plan candidates and calculating the number of all permutations, the query planner moves on to stack rank candidates and prune less-than-optimal options. In particularly complex queries, especially those where fields can be solved through multiple subgraphs, this can cause the number of all query plan permutations to balloon. In worst-case scenarios, this can end up being a number larger than Number.MAX_VALUE. In Javascript, if Number.MAX_VALUE is exceeded, Javascript represents the value as “infinity”. If the count of candidates is evaluated as infinity, the component of the query planner responsible for pruning less-than-optimal query plans does not actually prune candidates, causing the query planner to evaluate many orders of magnitude more query plan candidates than necessary. This issue has been addressed in @apollo/query-planner v2.8.5, @apollo/gateway v2.8.5, and Apollo Router v1.52.1. Users are advised to upgrade. This issue can be avoided by ensuring there are no fields resolvable from multiple subgraphs. If all subgraphs are using Federation 2, you can confirm that you are not impacted by ensuring that none of your subgraph schemas use the @shareable directive. If you are using Federation 1 subgraphs, you will need to validate that there are no fields resolvable by multiple subgraphs.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

Apollo Federation query planner infinite loop on complex queries with shared fields leads to denial-of-service via memory exhaustion.

Vulnerability

Overview

CVE-2024-43414 is a denial-of-service vulnerability in Apollo Federation's query planner component. The root cause is that when the query planner processes a sufficiently complex GraphQL query, it attempts to use a number exceeding JavaScript's Number.MAX_VALUE while evaluating candidate execution steps, causing an infinite loop. This affects @apollo/query-planner versions >=2.0.0 and <2.8.5, @apollo/gateway versions >=2.0.0 and <2.8.5, and Apollo Router versions <1.52.1, all of which rely on the query planner [1][3].

Exploitation

Conditions

An attacker can trigger the vulnerability by sending a crafted GraphQL query that exploits the presence of at least one non-@key field that can be resolved by multiple subgraphs (i.e., shared fields). In Federation 1 subgraphs, fields are implicitly shareable; in Federation 2 subgraphs, fields must be explicitly marked with the @shareable directive. The query planner's infinite loop occurs when it generates a large number of candidate execution steps for such shared fields, eventually exceeding the numeric limit [3].

Impact

Successful exploitation leads to unbounded memory consumption as the query planner never completes its planning. This results in either a crash or out-of-memory (OOM) termination of the affected service, causing a denial-of-service condition. No data confidentiality or integrity is compromised, but service availability is severely impacted [1][3].

Mitigation

The vulnerability has been patched in @apollo/query-planner version 2.8.5, @apollo/gateway version 2.8.5, and Apollo Router version 1.52.1. Users are strongly advised to upgrade to these or later versions. The fix addresses the numeric overflow issue in the candidate evaluation logic [4].

References

AI Insight generated on May 20, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected packages

Versions sourced from the GitHub Security Advisory.

Package	Affected versions	Patched versions
apollo-routercrates.io	< 1.52.1	1.52.1
@apollo/query-plannernpm	>= 2.0.0, < 2.8.5	2.8.5
@apollo/gatewaynpm	>= 2.0.0, < 2.8.5	2.8.5

Affected products

ghsa-coords3 versions
pkg:cargo/apollo-router pkg:npm/%40apollo/gateway pkg:npm/%40apollo/query-planner
< 1.52.1+ 2 more
- (no CPE)range: < 1.52.1
- (no CPE)range: >= 2.0.0, < 2.8.5
- (no CPE)range: >= 2.0.0, < 2.8.5
apollographql/federationv5
Range: >= 2.0.0, < 2.8.5

Patches

e309c9bb5a48

fix(security): CVE-2024-43414: Update query planner to resolve uncontrolled recursion

https://github.com/apollographql/routerJesse RosenbergerAug 27, 2024via ghsa

commit

4 files changed · +11 −11

apollo-router/Cargo.toml+1 −1 modified

@@ -197,7 +197,7 @@ regex = "1.10.5"
 reqwest.workspace = true
 
 # note: this dependency should _always_ be pinned, prefix the version with an `=`
-router-bridge = "=0.5.27+v2.8.1"
+router-bridge = "=0.5.31+v2.8.5"
 
 rust-embed = { version = "8.4.0", features = ["include-exclude"] }
 rustls = "0.21.12"

apollo-router/tests/integration/redis.rs+7 −7 modified

@@ -26,7 +26,7 @@ async fn query_planner_cache() -> Result<(), BoxError> {
     // 2. run `docker compose up -d` and connect to the redis container by running `docker-compose exec redis /bin/bash`.
     // 3. Run the `redis-cli` command from the shell and start the redis `monitor` command.
     // 4. Run this test and yank the updated cache key from the redis logs.
-    let known_cache_key = "plan:0:v2.8.1:16385ebef77959fcdc520ad507eb1f7f7df28f1d54a0569e3adabcb4cd00d7ce:3973e022e93220f9212c18d0d0c543ae7c309e46640da93a4a0314de999f5112:3106dfc3339d8c3f3020434024bff0f566a8be5995199954db5a7525a7d7e67a";
+    let known_cache_key = "plan:0:v2.8.5:16385ebef77959fcdc520ad507eb1f7f7df28f1d54a0569e3adabcb4cd00d7ce:3973e022e93220f9212c18d0d0c543ae7c309e46640da93a4a0314de999f5112:3106dfc3339d8c3f3020434024bff0f566a8be5995199954db5a7525a7d7e67a";
 
     let config = RedisConfig::from_url("redis://127.0.0.1:6379").unwrap();
     let client = RedisClient::new(config, None, None, None);
@@ -909,7 +909,7 @@ async fn connection_failure_blocks_startup() {
 async fn query_planner_redis_update_query_fragments() {
     test_redis_query_plan_config_update(
         include_str!("fixtures/query_planner_redis_config_update_query_fragments.router.yaml"),
-        "plan:0:v2.8.1:a9e605fa09adc5a4b824e690b4de6f160d47d84ede5956b58a7d300cca1f7204:3973e022e93220f9212c18d0d0c543ae7c309e46640da93a4a0314de999f5112:9054d19854e1d9e282ac7645c612bc70b8a7143d43b73d44dade4a5ec43938b4",
+        "plan:0:v2.8.5:a9e605fa09adc5a4b824e690b4de6f160d47d84ede5956b58a7d300cca1f7204:3973e022e93220f9212c18d0d0c543ae7c309e46640da93a4a0314de999f5112:9054d19854e1d9e282ac7645c612bc70b8a7143d43b73d44dade4a5ec43938b4",
     )
     .await;
 }
@@ -928,7 +928,7 @@ async fn query_planner_redis_update_planner_mode() {
 async fn query_planner_redis_update_introspection() {
     test_redis_query_plan_config_update(
         include_str!("fixtures/query_planner_redis_config_update_introspection.router.yaml"),
-        "plan:0:v2.8.1:a9e605fa09adc5a4b824e690b4de6f160d47d84ede5956b58a7d300cca1f7204:3973e022e93220f9212c18d0d0c543ae7c309e46640da93a4a0314de999f5112:04b3051125b5994fba6b0a22b2d8b4246cadc145be030c491a3431655d2ba07a",
+        "plan:0:v2.8.5:a9e605fa09adc5a4b824e690b4de6f160d47d84ede5956b58a7d300cca1f7204:3973e022e93220f9212c18d0d0c543ae7c309e46640da93a4a0314de999f5112:04b3051125b5994fba6b0a22b2d8b4246cadc145be030c491a3431655d2ba07a",
     )
     .await;
 }
@@ -937,7 +937,7 @@ async fn query_planner_redis_update_introspection() {
 async fn query_planner_redis_update_defer() {
     test_redis_query_plan_config_update(
         include_str!("fixtures/query_planner_redis_config_update_defer.router.yaml"),
-        "plan:0:v2.8.1:a9e605fa09adc5a4b824e690b4de6f160d47d84ede5956b58a7d300cca1f7204:3973e022e93220f9212c18d0d0c543ae7c309e46640da93a4a0314de999f5112:3b7241b0db2cd878b79c0810121953ba544543f3cb2692aaf1a59184470747b0",
+        "plan:0:v2.8.5:a9e605fa09adc5a4b824e690b4de6f160d47d84ede5956b58a7d300cca1f7204:3973e022e93220f9212c18d0d0c543ae7c309e46640da93a4a0314de999f5112:3b7241b0db2cd878b79c0810121953ba544543f3cb2692aaf1a59184470747b0",
     )
     .await;
 }
@@ -948,7 +948,7 @@ async fn query_planner_redis_update_type_conditional_fetching() {
         include_str!(
             "fixtures/query_planner_redis_config_update_type_conditional_fetching.router.yaml"
         ),
-        "plan:0:v2.8.1:a9e605fa09adc5a4b824e690b4de6f160d47d84ede5956b58a7d300cca1f7204:3973e022e93220f9212c18d0d0c543ae7c309e46640da93a4a0314de999f5112:0ca695a8c4c448b65fa04229c663f44150af53b184ebdcbb0ad6862290efed76",
+        "plan:0:v2.8.5:a9e605fa09adc5a4b824e690b4de6f160d47d84ede5956b58a7d300cca1f7204:3973e022e93220f9212c18d0d0c543ae7c309e46640da93a4a0314de999f5112:0ca695a8c4c448b65fa04229c663f44150af53b184ebdcbb0ad6862290efed76",
     )
     .await;
 }
@@ -959,7 +959,7 @@ async fn query_planner_redis_update_reuse_query_fragments() {
         include_str!(
             "fixtures/query_planner_redis_config_update_reuse_query_fragments.router.yaml"
         ),
-        "plan:0:v2.8.1:a9e605fa09adc5a4b824e690b4de6f160d47d84ede5956b58a7d300cca1f7204:3973e022e93220f9212c18d0d0c543ae7c309e46640da93a4a0314de999f5112:f7c04319556397ec4b550aa5aaa96c73689cee09026b661b6a9fc20b49e6fa77",
+        "plan:0:v2.8.5:a9e605fa09adc5a4b824e690b4de6f160d47d84ede5956b58a7d300cca1f7204:3973e022e93220f9212c18d0d0c543ae7c309e46640da93a4a0314de999f5112:f7c04319556397ec4b550aa5aaa96c73689cee09026b661b6a9fc20b49e6fa77",
     )
     .await;
 }
@@ -982,7 +982,7 @@ async fn test_redis_query_plan_config_update(updated_config: &str, new_cache_key
     router.assert_started().await;
     router.clear_redis_cache().await;
 
-    let starting_key = "plan:0:v2.8.1:a9e605fa09adc5a4b824e690b4de6f160d47d84ede5956b58a7d300cca1f7204:3973e022e93220f9212c18d0d0c543ae7c309e46640da93a4a0314de999f5112:4a5827854a6d2efc85045f0d5bede402e15958390f1073d2e77df56188338e5a";
+    let starting_key = "plan:0:v2.8.5:a9e605fa09adc5a4b824e690b4de6f160d47d84ede5956b58a7d300cca1f7204:3973e022e93220f9212c18d0d0c543ae7c309e46640da93a4a0314de999f5112:4a5827854a6d2efc85045f0d5bede402e15958390f1073d2e77df56188338e5a";
     router.execute_default_query().await;
     router.assert_redis_cache_contains(starting_key, None).await;
     router.update_config(updated_config).await;

Cargo.lock+2 −2 modified

@@ -6096,9 +6096,9 @@ dependencies = [
 
 [[package]]
 name = "router-bridge"
-version = "0.5.27+v2.8.1"
+version = "0.5.31+v2.8.5"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "288fa40fc4e0a76fb911410e05d4525e8bf7558622bd02403f89f871c4d0785b"
+checksum = "672901b1ec6fd110ac41d61ca5e1754319d0edf39546a089a114ab865d42ae97"
 dependencies = [
  "anyhow",
  "async-channel 1.9.0",

fuzz/Cargo.toml+1 −1 modified

@@ -20,7 +20,7 @@ reqwest = { workspace = true, features = ["json", "blocking"] }
 serde_json.workspace = true
 tokio.workspace = true
 # note: this dependency should _always_ be pinned, prefix the version with an `=`
-router-bridge = "=0.5.27+v2.8.1"
+router-bridge = "=0.5.31+v2.8.5"
 
 [dev-dependencies]
 anyhow = "1"

Vulnerability mechanics

Generated on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

github.com/advisories/GHSA-fmj9-77q8-g6c4ghsaADVISORY
nvd.nist.gov/vuln/detail/CVE-2024-43414ghsaADVISORY
github.com/apollographql/federation/security/advisories/GHSA-fmj9-77q8-g6c4ghsax_refsource_CONFIRMWEB
github.com/apollographql/router/commit/e309c9bb5a48c1304ff69c88b7eabdd08c26bf45ghsaWEB
www.apollographql.com/docs/federation/query-plansghsax_refsource_MISCWEB
www.apollographql.com/docs/router/configuration/persisted-queriesghsax_refsource_MISCWEB

News mentions

No linked articles in our index yet.

cvss	0.455
epss	0.000
exploit	0.000
kev	0.000
patch	-0.070
ransomware	0.000