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.
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.
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.
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.
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:
graphql 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:
graphql 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.MAXVALUE in some cases. In Javascript, Number.MAXVALUE 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.MAXVALUE. In Javascript, if Number.MAXVALUE 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:
graphql 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.MAXVALUE:
graphql query { field1: field field2: field # ... field1023: field field1024: 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
Impact
Instances of the Apollo Router using either of the following may be impacted by a denial-of-service vulnerability.
1. External Coprocessing with specific configurations; or 2. 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:
1. Router has been configured to support External Coprocessing. 2. 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:
yaml ... 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:
1. Router has been configured to use a custom-developed Native Rust Plugin 2. The plugin accesses Request.routerrequest in the RouterService layer 3. You are accumulating the body from Request.routerrequest 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 routerservice method.
You can check for a defined plugin by reviewing for the following in your Router’s configuration YAML:
yaml ... plugins: custompluginname: # custom config here ...
You can check for a custom routerservice method in a plugin, by reviewing for the following function signature in your plugin’s source:
rust fn routerservice(&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.httpmaxrequestbytes. 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.httpmaxrequestbytes 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