apollo-router

A configurable, high-performance routing runtime for Apollo Federation 🚀

View on Cargo

View on Github

Activity

Latest release: 2w ago
Total releases: 322
Cadence: ~daily
Last 12 months: 68

Reach

Downloads: 597.6k
Stars: 972

Details

License: Elastic-2.0
First release: Oct 21, 2021

Releases

Version	Released
`2.18.0-rc.0` pre	Aug 28, 2026
`2.16.3` patch	Aug 27, 2026
`2.16.3-rc.0` pre	Aug 26, 2026
`2.16.2` patch	Aug 13, 2026
`2.16.2-rc.1` pre	Aug 13, 2026
`2.16.2-rc.0` pre	Aug 12, 2026
`3.0.0-alpha.2` pre	Aug 05, 2026
`2.17.0` unknown	Jul 24, 2026
`2.17.0-rc.0` unknown	Jul 23, 2026
`2.10.5` unknown	Jul 21, 2026
`2.16.1` unknown	Jul 21, 2026
`2.16.0` unknown	Jun 30, 2026
`2.16.0-rc.1` unknown	Jun 25, 2026
`2.16.0-rc.0` unknown	Jun 24, 2026
`2.15.1` unknown	Jun 10, 2026
`2.10.4` unknown	Jun 02, 2026
`2.10.4-rc.0` unknown	Jun 02, 2026
`2.10.3` unknown	Jun 01, 2026
`2.10.3-rc.0` unknown	May 27, 2026
`2.15.0` unknown	May 26, 2026
`2.15.0-rc.0` unknown	May 21, 2026
`2.14.2` unknown	May 21, 2026
`2.14.2-rc.0` unknown	May 21, 2026
`2.14.1` unknown	May 20, 2026
`2.14.1-rc.0` unknown	May 14, 2026
`2.14.0` unknown	Apr 28, 2026
`2.14.0-rc.2` unknown	Apr 24, 2026
`2.14.0-rc.1` unknown	Apr 23, 2026
`2.14.0-rc.0` unknown	Apr 23, 2026
`2.13.1` unknown	Apr 03, 2026
`2.13.1-rc.0` unknown	Apr 01, 2026
`2.13.0` unknown	Mar 31, 2026
`2.13.0-rc.0` unknown	Mar 27, 2026
`2.12.1` unknown	Mar 24, 2026
`1.61.13` unknown	Mar 24, 2026
`2.12.1-rc.0` unknown 1 CVE	Mar 24, 2026
`1.61.13-rc.0` unknown 1 CVE	Mar 24, 2026
`2.10.2` unknown	Mar 24, 2026
`2.10.2-rc.0` unknown 1 CVE	Mar 24, 2026
`2.10.1` unknown 1 CVE	Mar 11, 2026
`2.10.1-rc.2` unknown 1 CVE	Mar 11, 2026
`2.10.1-rc.1` unknown 1 CVE	Mar 10, 2026
`2.12.0` unknown 1 CVE	Feb 24, 2026
`2.12.0-rc.1` unknown 1 CVE	Feb 18, 2026
`2.12.0-rc.0` unknown 1 CVE	Feb 18, 2026
`2.12.0-alpha.0` unknown 1 CVE	Feb 18, 2026
`2.11.0` unknown 1 CVE	Jan 27, 2026
`2.11.0-rc.0` unknown	Jan 22, 2026
`2.11.0-abstract.1` unknown	Dec 18, 2025
`2.10.0` unknown 1 CVE	Dec 12, 2025

1–50 of 322

Repository

apollographql/router

Forks: 341
Open issues: 196
Language: Rust

graphql
federation
apollo
graph-router
federated-graph
gateway

Dependencies (184)

Depends on

2.18.0-rc.0

Used by

Supply-chain exposure

2 tracked projects depend on this, <1% of every package we track.

A known CVE here directly exposes every one of them.

Vulnerable dependencies

4 of 170

derivative 1 CVE
paste 1 CVE
rustls-pemfile 1 CVE
yaml-rust 1 CVE

These dependencies are still vulnerable in their latest release. Whether the exact version this package pins is affected isn't checked yet.

Known CVEs (13)

GHSA-hff2-gcpx-8f4p Mar 26, 2026

Apollo Router Core: Browser Bug Enables Bypass of XS-Search Prevention via Read-Only Cross-Site Request Forgery

Medium
Network High None None

Impact

In a Cross-Site Request Forgery attack, untrusted web content causes browsers to send authenticated requests to web servers which use cookies for authentication. While the web content is prevented from reading the request's response due to the Cross-Origin Request Sharing (CORS) protocol, the attacker may be able to cause side effects in the server ("CSRF" attack), or learn something about the response via timing analysis ("XS-Search" attack).

Apollo Router has a built-in feature which prevents CSRF and XS-Search attacks: it refuses to process GraphQL requests that could possibly have been sent by a spec-compliant web browser without a protective "preflight" step. See Apollo Router's docs for more details on CORS, CSRF attacks, and Apollo Router's CSRF prevention feature.

This feature is fully effective against attacks carried out against users of spec-compliant browsers. Unfortunately, a major browser introduced a bug in 2025 which meant in certain cases, it failed to follow the CORS spec. The browser's maintainers have already committed to fixing the bug and making the browser spec-compliant again.

Even with this bug, Apollo Router's CSRF prevention feature blocks "side effect" CSRF attacks: Apollo Router will still correctly refuse to execute mutations in requests that were not preflighted. However, some specially crafted authenticated GraphQL queries can be issued across origins without preflight in buggy versions of this browser, allowing for XS-Search attacks: an attacker can analyze response times to learn facts about the responses to requests such as whether fields return null or approximately how many list entries are returned from fields.

Apollo Router installations are only vulnerable if they rely on cookies (or HTTP Basic Auth) for authentication.

Patches

The vulnerability is patched in the following versions of Apollo Router:

2.12.1 (latest)

2.10.2 (v2.10 LTS)

1.61.13 (v1; note that Router v1 reaches end-of-support on March 31 2026)

These releases contain a single change: GraphQL requests sent in HTTP GET requests which contain a Content-Type header naming a type other than application/json are rejected. (GET requests with no Content-Type are allowed.) This change prevents XS-Search attacks even in browsers which are non-compliant in ways similar to this browser.

There are no known cases where GraphQL apps depend on the ability of clients to send non-empty Content-Type headers with GET requests other than application/json, so this change has not been made configurable; if this change breaks a specific use case, contact support and more configurability can be added.

Workarounds

If upgrading is not possible, this particular browser's bug can be mitigated by preventing any HTTP request with a Content-Type header containing message/ from reaching the Apollo Router (e.g. in a load balancer/proxy).

If the load balancer cannot easily be updated to block these requests, it can also be done with a Rhai script within Router:

# config.yaml rhai: scripts: "/directory/with/rhai/script" main: "main.rhai" # main.rhai fn router_service(service) { const request_callback = Fn("process_request"); service.map_request(request_callback); } fn process_request(request) { if "content-type" in request.headers { if request.headers["content-type"].contains("message/") { throw "Error: invalid content type" } } }

While the patch prevents a broader class of similar issues, the only known way to exploit this vulnerability is against a particular browser which currently plans to ship a fix in May 2026. If it is already past June 2026 and this vulnerability has not been addressed yet, it is likely that the installation is not currently vulnerable. Upgrading to the latest version of Apollo Router is still recommended for the broader protection.

Resources

The browser bug causes a similar vulnerability in Apollo Server; see https://github.com/apollographql/apollo-server/security/advisories/GHSA-9q82-xgwf-vj

Fixed in

1.61.132.10.22.12.1

References

https://github.com/apollographql/apollo-server/security/advisories/GHSA-9q82-xgwf-vj6h
https://github.com/apollographql/router/security/advisories/GHSA-hff2-gcpx-8f4p
https://github.com/apollographql/router/commit/a72e759bcdeef93fcd3dc928cf3c1f4bbebdcc65
https://github.com/apollographql/router
https://github.com/apollographql/router/releases/tag/v2.12.1
https://www.apollographql.com/docs/graphos/resources/runtime-release-lifecycle#end-of-support-eos

Updated Mar 26, 2026 · Source: OSV.dev
CVE-2025-64173 GHSA-x33c-7c2v-mrj9 Nov 06, 2025

Apollo Router Affected by an Access Control Bypass on Polymorphic Types

7.5 / 10
High
Network Low None None Unchanged High None None

Summary

A vulnerability in Apollo Router allowed for unauthenticated queries to access data that required additional access controls. Router incorrectly handled access control directives on interface types/fields and their implementing object types/fields, applying them to interface types/fields while ignoring directives on their implementing object types/fields when all implementations had the same requirements.

Details

Apollo Federation allows users to specify access control directives (@authenticated, @requiresScopes, and @policy) to protect object and interface types and fields. However, the GraphQL specification does not define inheritance rules for directives from interfaces to their implementations. Apollo Router will enforce any directives on the interface types/fields but ignore any directives on the implementation object types/fields (as long as all implementations have the same requirements). This inconsistent enforcement behavior leads to unexpected runtime security gaps.

Who is impacted

This vulnerability impacts Apollo Router customers defining @authenticated, @requiresScopes, or @policy directives inconsistently on polymorphic types (i.e., object types that implement interface types). Specifically, if the same access control directives are applied to all implementing types/fields but not on their implemented interface types/fields, they could be impacted.

Scope of Impact

This vulnerability could allow a malicious actor to craft a query that can bypass access control requirements on the object types/fields by instead querying them via implemented interface types/fields that don't have the same access control requirements.

Patches

This vulnerability has been fixed at runtime in Apollo Router. You may update Router to one of the following versions:

1.61.12+

2.8.1+

Workarounds

If you are not immediately updating Router to a patched version, you should apply any included access control requirements to both the appropriate interface types/fields and their implementations.

Customers not using Apollo Router access control features (@authenticated, @requiresScopes, or @policy directives) or not specifying inconsistent access control requirements on polymorphic types/fields are not affected and do not need to take action.

Fixed in

1.61.122.8.1

References

https://github.com/apollographql/router/security/advisories/GHSA-x33c-7c2v-mrj9
https://nvd.nist.gov/vuln/detail/CVE-2025-64173
https://github.com/apollographql/router/commit/75ca43ecb9d38423b63d09896702f9da425cc754
https://github.com/apollographql/router
https://github.com/apollographql/router/releases/tag/v2.8.1
https://www.apollographql.com/docs/graphos/routing/security/authorization#authorization-directives

Updated Nov 06, 2025 · Source: OSV.dev
CVE-2025-64347 GHSA-g8jh-vg5j-4h3f Nov 06, 2025

Apollo Router Improperly Enforces Renamed Access Control Directives

7.5 / 10
High
Network Low None None Unchanged High None None

Summary

A vulnerability in Apollo Router allowed for unauthorized access to protected data through schema elements with access control directives (@authenticated, @requiresScopes, and @policy) that were renamed via @link imports. Router did not enforce renamed access control directives on schema elements (e.g. fields and types), allowing queries to bypass those element-level access controls.

Details

Apollo Federation allows users to specify access control directives (@authenticated, @requiresScopes, and @policy](https://www.apollographql.com/docs/graphos/routing/security/authorization#authorization-directives)) to protect schema data access at the element level. These directives can optionally be renamed via the imports argument to the @link directive, which can be useful if their default names match an existing user-defined directive in their subgraph schema. However, Apollo Router's access control logic ignored the imports argument, and would accordingly ignore access control directives that were renamed in this way.

Who Is Impacted

This vulnerability impacts Apollo Router customers defining @authenticated, @requiresScopes, or @policy directives on schema elements that were renamed via @link imports are impacted.

Scope of Impact

The vulnerability could allow a malicious actor to craft a query that can bypass access control requirements on schema elements protected by renamed access control directives.

Patches

This vulnerability has been fixed in Apollo Router by updating the access control logic to handle the imports argument in @link directives. You will need to update Router to one of the following versions:

1.61.12+

2.8.1+

Workarounds

If you are not immediately updating Router to a patched version, you should remove any renames of access control directives in the imports argument to the @link directive.

Customers not using Apollo Router with renamed access control directives (@authenticated, @requiresScopes, and @policy) are not affected and do not need to take action.

Fixed in

1.61.122.8.1

References

https://github.com/apollographql/router/security/advisories/GHSA-g8jh-vg5j-4h3f
https://nvd.nist.gov/vuln/detail/CVE-2025-64347
https://github.com/apollographql/router/commit/78e4b20a2fc26cc5f141aa47992ed85375266a2b
https://github.com/apollographql/router

Updated Nov 07, 2025 · Source: OSV.dev
CVE-2025-32380 GHSA-3j43-9v8v-cp3f Apr 07, 2025

Apollo Router Query Validation Vulnerable to Excessive Resource Consumption via Named Fragment Processing

7.5 / 10
High
Network Low None None Unchanged None None High

Impact

Summary

A vulnerability in Apollo Router's usage of Apollo Compiler allowed queries with deeply nested and reused named fragments to be prohibitively expensive to validate. This could lead to excessive resource consumption and denial of service.

Details

Named fragments were being processed once per fragment spread in some cases during query validation, leading to exponential resource usage when deeply nested and reused fragments were involved.

Fix/Mitigation

Apollo Router's usage of Apollo Compiler has been updated so that validation logic processes each named fragment only once, preventing redundant traversal.

Patches

This has been remediated in apollo-router versions 1.61.2 and 2.1.1.

Workarounds

The only known workaround is "Safelisting with IDs only" per Safelisting with Persisted Queries - Apollo GraphQL Docs. The "Safelisting" security level is not sufficient, since that level allows freeform GraphQL queries to be sent to Apollo Router.

References

Query Planning Documentation

Acknowledgements

We appreciate the efforts of the security community in identifying and improving the performance and security of query validation mechanisms.

Fixed in

1.61.22.1.1

References

https://github.com/apollographql/router/security/advisories/GHSA-3j43-9v8v-cp3f
https://nvd.nist.gov/vuln/detail/CVE-2025-32380
https://github.com/apollographql/router/commit/ab6675a63174715ea6ff50881fc957831d4e9564
https://github.com/apollographql/router/commit/bba032e183b861348a466d3123c7137a1ae18952
https://github.com/apollographql/router

Updated Apr 09, 2025 · Source: OSV.dev
CVE-2025-32033 GHSA-84m6-5m72-45fp Apr 07, 2025

Apollo Router Operation Limits Vulnerable to Bypass via Integer Overflow

7.5 / 10
High
Network Low None None Unchanged None None High

Impact

Summary

A vulnerability in Apollo Router allowed certain queries to bypass configured operation limits, specifically due to integer overflow.

Details

The operation limits plugin uses unsigned 32-bit integers to track limit counters (e.g. for a query's height). If a counter exceeded the maximum value for this data type (4,294,967,295), it wrapped around to 0, unintentionally allowing queries to bypass configured thresholds. This could occur for large queries if the payload limit were sufficiently increased, but could also occur for small queries with deeply nested and reused named fragments.

Fix/Mitigation

Logic was updated to ensure counter overflow is handled correctly and does not wrap around to 0.

Patches

This has been remediated in apollo-router versions 1.61.2 and 2.1.1.

Workarounds

The only known workaround is "Safelisting" or "Safelisting with IDs only" per Safelisting with Persisted Queries - Apollo GraphQL Docs.

Acknowledgements

We appreciate the efforts of the security community in identifying and improving the performance and security of operation limiting mechanisms.

Fixed in

1.61.22.1.1

References

https://github.com/apollographql/router/security/advisories/GHSA-84m6-5m72-45fp
https://nvd.nist.gov/vuln/detail/CVE-2025-32033
https://github.com/apollographql/router/commit/ab6675a63174715ea6ff50881fc957831d4e9564
https://github.com/apollographql/router/commit/bba032e183b861348a466d3123c7137a1ae18952
https://github.com/apollographql/router

Updated Apr 08, 2025 · Source: OSV.dev
CVE-2025-32034 GHSA-75m2-jhh5-j5g2 Apr 07, 2025

Apollo Router Query Planner Vulnerable to Excessive Resource Consumption via Named Fragment Expansion

7.5 / 10
High
Network Low None None Unchanged None None High

Impact

Summary

A vulnerability in Apollo Router allowed queries with deeply nested and reused named fragments to be prohibitively expensive to query plan, specifically during named fragment expansion. This could lead to excessive resource consumption and denial of service.

Details

Named fragments were being expanded once per fragment spread during query planning, leading to exponential resource usage when deeply nested and reused fragments were involved.

Fix/Mitigation

A new Query Fragment Expansion Limit metric has been introduced:

This metric computes the number of selections a query would have if its fragment spreads were fully expanded.

The metric is checked against a limit to prevent excessive computation.

Patches

This has been remediated in apollo-router versions 1.61.2 and 2.1.1.

Workarounds

The only known workaround is "Safelisting" or "Safelisting with IDs only" per Safelisting with Persisted Queries - Apollo GraphQL Docs.

References

Query Planning Documentation

Acknowledgements

We appreciate the efforts of the security community in identifying and improving the performance and security of query planning mechanisms.

Fixed in

1.61.22.1.1

References

https://github.com/apollographql/router/security/advisories/GHSA-75m2-jhh5-j5g2
https://nvd.nist.gov/vuln/detail/CVE-2025-32034
https://github.com/apollographql/router/commit/ab6675a63174715ea6ff50881fc957831d4e9564
https://github.com/apollographql/router/commit/bba032e183b861348a466d3123c7137a1ae18952
https://github.com/apollographql/router

Updated Apr 08, 2025 · Source: OSV.dev
CVE-2025-32032 GHSA-94hh-jmq8-2fgp Apr 07, 2025

Apollo Router Query Planner Vulnerable to Excessive Resource Consumption via Optimization Bypass

7.5 / 10
High
Network Low None None Unchanged None None High

Impact

Summary

A vulnerability in Apollo Router allowed queries with deeply nested and reused named fragments to be prohibitively expensive to query plan, specifically due to internal optimizations being frequently bypassed. This could lead to excessive resource consumption and denial of service.

Details

The query planner includes an optimization that significantly speeds up planning for applicable GraphQL selections. However, queries with deeply nested and reused named fragments can generate many selections where this optimization does not apply, leading to significantly longer planning times. Because the query planner does not enforce a timeout, a small number of such queries can exhaust router's thread pool, rendering it inoperable.

Fix/Mitigation

A new Query Optimization Limit metric has been added:

This metric approximates the number of selections that cannot be skipped by the existing optimization.

The metric is checked against a limit to prevent excessive computation.

Given the complexity of query planning optimizations, we will continue refining these solutions based on real-world performance and accuracy tests.

Patches

This has been remediated in apollo-router versions 1.61.2 and 2.1.1.

Workarounds

The only known workaround is "Safelisting" or "Safelisting with IDs only" per Safelisting with Persisted Queries - Apollo GraphQL Docs.

References

Query Planning Documentation

Acknowledgements

We appreciate the efforts of the security community in identifying and improving the performance and security of query planning mechanisms.

Fixed in

1.61.22.1.1

References

https://github.com/apollographql/router/security/advisories/GHSA-94hh-jmq8-2fgp
https://nvd.nist.gov/vuln/detail/CVE-2025-32032
https://github.com/apollographql/router/commit/ab6675a63174715ea6ff50881fc957831d4e9564
https://github.com/apollographql/router/commit/bba032e183b861348a466d3123c7137a1ae18952
https://github.com/apollographql/router

Updated Apr 08, 2025 · Source: OSV.dev
CVE-2024-43783 GHSA-x6xq-whh3-gg32 Aug 27, 2024

Apollo Router Coprocessors may cause Denial-of-Service when handling request bodies

High
Network Low None None

Impact

Instances of the Apollo Router using either of the following may be impacted by a denial-of-service vulnerability.

External Coprocessing with specific configurations; or

Native Rust Plugins accessing the Router request body in the RouterService layer

Router customizations using Rhai scripts are not impacted.

When using External Coprocessing:

Instances of the Apollo Router running versions >=1.21.0 and <1.52.1 are impacted by a denial-of-service vulnerability if all of the following are true:

Router has been configured to support External Coprocessing.

Router has been configured to send request bodies to coprocessors. This is a non-default configuration and must be configured intentionally by administrators.

You can identify if you are impacted by reviewing your router's configuration YAML for the following config:

... coprocessor: url: http://localhost:9000 # likely different in your environment router: request: body: true # this must be set to 'true' to be impacted ...

External Coprocessing was initially made available as an experimental feature with Router version 1.21.0 on 2023-06-20 and was made generally available with Router version 1.38.0 on 2024-01-19. More information about the Router’s External Coprocessing feature is available here.

When using Native Rust Plugins:

Instances of the Apollo Router running versions >=1.7.0 and <1.52.1 are impacted by a denial-of-service vulnerability if all of the following are true:

Router has been configured to use a custom-developed Native Rust Plugin

The plugin accesses Request.router_request in the RouterService layer

You are accumulating the body from Request.router_request into memory

To use a plugin, you need to be running a customized Router binary. Additionally, you need to have a plugins section with at least one plugin defined in your Router’s configuration YAML. That plugin would also need to define a custom router_service method.

You can check for a defined plugin by reviewing for the following in your Router’s configuration YAML:

... plugins: custom_plugin_name: # custom config here ...

You can check for a custom router_service method in a plugin, by reviewing for the following function signature in your plugin’s source:

fn router_service(&self, service: router::BoxService) -> router::BoxService

More information about the Router’s Native Rust Plugin feature is available here.

Impact Detail

If using an impacted configuration, the Router will load entire HTTP request bodies into memory without respect to other HTTP request size-limiting configurations like limits.http_max_request_bytes. This can cause the Router to be out-of-memory (OOM) terminated if a sufficiently large request is sent to the Router.

By default, the Router sets limits.http_max_request_bytes to 2 MB. More information about the Router’s request limiting features is available here.

Patches

Apollo Router 1.52.1

If you have an impacted configuration as defined above, please upgrade to at least Apollo Router 1.52.1.

Workarounds

If you cannot upgrade, you can mitigate the denial-of-service opportunity impacting External Coprocessors by setting the coprocessor.router.request.body configuration option to false. Please note that changing this configuration option will change the information sent to any coprocessors you have configured and may impact functionality implemented by those coprocessors.

If you have developed a Native Rust Plugin and cannot upgrade, you can update your plugin to either not accumulate the request body or enforce a maximum body size limit.

You can also mitigate this issue by limiting HTTP body payload sizes prior to the Router (e.g., in a proxy or web application firewall appliance).

References

Apollo Router 1.52.1 Release Notes External Coprocessing documentation HTTP Request Limiting documentation Native Rust Plugin documentation

Fixed in

1.52.1

References

https://github.com/apollographql/router/security/advisories/GHSA-x6xq-whh3-gg32
https://nvd.nist.gov/vuln/detail/CVE-2024-43783
https://github.com/apollographql/router/commit/7a9c020608a62dcaa306b72ed0f6980f15923b14
https://github.com/apollographql/router
https://github.com/apollographql/router/releases/tag/v1.52.1
https://www.apollographql.com/docs/router/configuration/overview/#request-limits

Updated Aug 27, 2024 · Source: OSV.dev
CVE-2024-43414 GHSA-fmj9-77q8-g6c4 Aug 27, 2024

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

High
Network Low None None

Impact

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-planner.

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.

To review Federation 1 subgraphs for impact:

In Federation 1 subgraphs, fields are implicitly shareable across subgraphs. To review for impact, you will need to review for cases where multiple subgraphs can resolve the same field. For example:

# Subgraph 1 type Query { field: Int } # Subgraph 2 type Query { field: Int }

To review Federation 2 subgraphs for impact:

In Federation 2 subgraphs, fields must be explicitly defined as shareable across subgraphs. This is done via the @shareable directive. For example:

# Subgraph 1 @link(url: "https://specs.apollo.dev/federation/v2.0") type Query { field: Int @shareable } # Subgraph 2 @link(url: "https://specs.apollo.dev/federation/v2.0") type Query { field: Int @shareable }

Impact Detail

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.

A given graph’s exposure to this issue varies based on its complexity. Consider the following Federation 2 subgraphs:

# Subgraph 1 type Query { field: Int @shareable } # Subgraph 2 type Query { field: Int @shareable }

The query planner can solve requests for Query.field in one of two ways - either by querying subgraph 1 or subgraph 2.

The following query with 1024 aliased fields would trigger this issue because 2^1024 > Number.MAX_VALUE:

query { field_1: field field_2: field # ... field_1023: field field_1024: field }

However, in a graph that provided 5 options to solve a given field, the bug could be encountered in a query that aliased the field approximately 440 times.

Patches

@apollo/query-planner 2.8.5 @apollo/gateway 2.8.5 Apollo Router 1.52.1

Workarounds

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.

Note that a supergraph can contain a mix of Federation 1 and Federation 2 subgraphs.

If you do have fields resolvable by multiple subgraphs, changing this behavior in response to this issue may be risky to the operation of your supergraph. We recommend that you update to a patched version of either Apollo Router or Apollo Gateway.

Apollo customers with an enterprise entitlement using the Apollo Router can also mitigate much of the risk from this issue by implementing Apollo’s Persisted Queries (PQ) feature. With PQ enabled, the Apollo Router will only execute safelisted queries. While customers would need to ensure that queries that induce this issue are not added to the safelist, PQs would mitigate the risk of clients submitting ad hoc queries that exploit this issue.

References

Additional information on Query Plans

Fixed in

1.52.1

References

https://github.com/apollographql/federation/security/advisories/GHSA-fmj9-77q8-g6c4
https://nvd.nist.gov/vuln/detail/CVE-2024-43414
https://github.com/apollographql/router/commit/e309c9bb5a48c1304ff69c88b7eabdd08c26bf45
https://github.com/apollographql/federation
https://www.apollographql.com/docs/federation/query-plans
https://www.apollographql.com/docs/router/configuration/persisted-queries

Updated Sep 13, 2024 · Source: OSV.dev
CVE-2024-32971 GHSA-q9p4-hw9m-fj2v May 02, 2024

Apollo Router vulnerable to Critical Regression In Query Plan Cache

9.0 / 10
Critical
Network High None None Changed High High High

Impact

Any instance of Apollo Router 1.44.0 or 1.45.0 that is using Distributed Query Plan Caching is impacted. These versions were released on 2024-04-12 and 2024-04-22 respectively.

The affected versions of Apollo Router contain a bug that could lead to unexpected operations being executed, which can result in unintended data or effects. This only affects Router instances configured to use distributed query plan caching. Router versions other than the ones listed above, and all Router deployments that are not using distributed query plan caching, are unaffected by this defect.

If you are using the affected versions, you can check your router’s configuration YAML to verify if you are impacted:

supergraph: query_planning: cache: # Look for this config below redis: urls: ["redis://..."]

A full reference on the Distributed Query Plan Caching feature is available here.

Impact detail

The root cause of this defect is a bug in Apollo Router’s cache retrieval logic: When this defect is present and distributed query planning caching is enabled, asking the Router to execute an operation (whether it is a query, a mutation, or a subscription) may result in an unexpected variation of that operation being executed or the generation of unexpected errors.

The issue stems from inadvertently executing a modified version of a previously executed operation, whose query plan is stored in the underlying cache (specifically, Redis). Depending on the type of the operation, the result may vary. For a query, results may be fetched that don’t match what was requested (e.g., rather than running fetchUsers(type: ENTERPRISE) the Router may run fetchUsers(type: TRIAL). For a mutation, this may result in incorrect mutations being sent to underlying subgraph servers (e.g., rather than sending deleteUser(id: 10) to a subgraph, the Router may run deleteUser(id: 12).

Patches

Apollo Router 1.45.1

If you are using distributed query plan caching, please either upgrade to version 1.45.1 or above or downgrade to version 1.43.2 of the Apollo Router. We do not recommend Apollo Router versions 1.44.0 or 1.45.0 for use and have withdrawn these releases. If you use impacted versions in production, we recommend that you migrate away immediately by redeploying to an unaffected Router version. For non-production use cases, we recommend you migrate at your earliest convenience.

Workarounds

If you cannot upgrade or downgrade, you can disable distributed query plan caching by removing the supergraph.query_planning.cache.redis.urls configuration. Please note that when distributed query plan caching is disabled, each Router instance will maintain its own in-memory query plan cache. This may increase resource utilization for each Router instance and could increase cold-start times as each Router instance builds its query plan cache.

References

Apollo Router 1.45.1 Release Notes

Fixed in

1.45.1

References

https://github.com/apollographql/router/security/advisories/GHSA-q9p4-hw9m-fj2v
https://nvd.nist.gov/vuln/detail/CVE-2024-32971
https://github.com/apollographql/router/commit/ff9f666598cd17661880fe7fc6e9c9611316e529
https://github.com/apollographql/router
https://github.com/apollographql/router/releases/tag/v1.45.1
https://www.apollographql.com/docs/router/configuration/distributed-caching/#distributed-query-plan-caching

Updated Sep 10, 2026 · Source: OSV.dev

1–10 of 13

Insights

Releases per month

last 12 months

Release mix

patch 2
pre 5
unknown 315

322 releases

Dependencies over time

per release

Release calendar

2026

Jan

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Less More