Impact The Apollo Router is a configurable, high-performance graph router written in Rust to run a federated supergraph that uses Apollo Federation. Affected versions are subject to a Denial-of-Service (DoS) type vulnerability which causes the Router to panic and terminate when a multi-part response is sent. When users send queries to the router that uses the @defer or Subscriptions, the Router will panic. To be vulnerable, users of Router must have a coprocessor with coprocessor.supergraph.response configured in their router.yaml and also to support either @defer or Subscriptions.

Patches Router version 1.33.0 has a fix for this vulnerability. https://github.com/apollographql/router/pull/4014 fixes the issue.

Workarounds For affected versions, avoid using the coprocessor supergraph response: yml do not use this stage in your coprocessor configuration coprocessor: supergraph: response:

Or you can disable defer and subscriptions support: yml disable defer and subscriptions: supergraph: defersupport: false # enabled by default subscription: enabled: false # disabled by default and continue to use the coprocessor supergraph response. References https://github.com/apollographql/router/issues/4013

Impact

This is a Denial-of-Service (DoS) type vulnerability which causes the Router to panic and terminate when GraphQL Subscriptions are enabled. It can be triggered when all of the following conditions are met:

1. Running Apollo Router v1.28.0, v1.28.1 or v1.29.0 ("impacted versions"); and 2. The Supergraph schema provided to the Router (either via Apollo Uplink or explicitly via other configuration) has a subscription type with root-fields defined; and 3. The YAML configuration provided to the Router has subscriptions enabled (they are disabled by default), either by setting enabled: true or by setting a valid mode within the subscriptions object (as seen in subscriptions' documentation); and 4. An anonymous (i.e., un-named) subscription operation (e.g., subscription { ... }) is received by the Router

If all four of these criteria are met, the impacted versions will panic and terminate. There is no data-privacy risk or sensitive-information exposure aspect to this vulnerability.

Depending on the environment in which impacted versions are running and the high-availability characteristics of that environment, a single Router's termination may result in limited or reduced availability or other knock-on effects which are deployment-specific (e.g., depending on if there are multiple instances, auto-restart policies, etc.)

Discovery

This vulnerability was discovered by an internal Apollo team. We have no reports or evidence to support that that has been exploited outside of our own testing, research and follow-up.

Our public security policy can be reviewed at https://github.com/apollographql/router/security/policy and we consider the security of our projects a top priority. Please review the linked policy for more details.

Patches

This is fixed in Apollo Router v1.29.1, which is available on:

- GitHub Releases as v1.29.1 - GitHub Packages Container Registry as v1.29.1 - Helm Chart Repository as 1.29.1 (without the v)

We recommend all users running the impacted configuration above to update to a patched version of the Router immediately. Router v1.29.1 should be a very simple upgrade from any impacted version.

Workarounds

Updating to v1.29.1 should be a clear and simple upgrade path for those running impacted versions. However, if Subscriptions are not necessary for your Graph – but are enabled via configuration — then disabling subscriptions is another option to mitigate the risk.

For more information

If you have any questions or comments about this advisory:

Open an issue in the router repository Email us at security [at] apollographql [dot] com

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