Impact

The @apollo/experimental-apollo-client-nextjs NPM package is vulnerable to a cross-site scripting vulnerability. This vulnerability arises from improper handling of untrusted input when @apollo/experimental-apollo-client-nextjs performs server-side rendering of HTML pages. To fix this vulnerability, we implemented appropriate escaping to prevent javascript injection into rendered pages.

Patches

To fix this issue, please update to version 0.7.0 or later.

Workarounds

There are no known workarounds for this issue. Please update to version 0.7.0

Apollo MCP Server is a Model Context Protocol server that exposes GraphQL operations as MCP tools. Prior to version 1.7.0, the Apollo MCP Server did not validate the Host header on incoming HTTP requests when using StreamableHTTP transport. In configurations where an HTTP-based MCP server is run on localhost without additional authentication or network-level controls, this could potentially allow a malicious website—visited by a user running the server locally—to use DNS rebinding techniques to bypass same-origin policy restrictions and issue requests to the local MCP server. If successfully exploited, this could allow an attacker to invoke tools or access resources exposed by the MCP server on behalf of the local user. This issue is limited to HTTP-based transport modes (StreamableHTTP). It does not affect servers using stdio transport. The practical risk is further reduced in deployments that use authentication, network-level access controls, or are not bound to localhost. This vulnerability is fixed in 1.7.0.

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. When receiving compressed HTTP payloads, affected versions of the Router evaluate the limits.httpmaxrequestbytes configuration option after the entirety of the compressed payload is decompressed. If affected versions of the Router receive highly compressed payloads, this could result in significant memory consumption while the compressed payload is expanded.

Patches Router version 1.40.2 has a fix for the vulnerability.

Workarounds If you are unable to upgrade, you may be able to implement mitigations at proxies or load balancers positioned in front of your Router fleet (e.g. Nginx, HAProxy, or cloud-native WAF services) by creating limits on HTTP body upload size.

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

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

Summary

A vulnerability in Apollo Gateway 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/gateway version 2.10.1.

Workarounds

No known direct workarounds exist.

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 Gateway 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 render gateway 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/gateway version 2.10.1.

Workarounds

No known direct workarounds exist.

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

The default configuration of startStandaloneServer from @apollo/server/standalone is vulnerable to Denial of Service (DoS) attacks through specially crafted request bodies with exotic character set encodings.

This issue does not affect users that use @apollo/server as a dependency for integration packages, like @as integrations/express5 or @as-integrations/next, only direct usage of startStandaloneServer.

Who is impacted

Users directly using startStandaloneServer from @apollo/server/standalone.

This issue affects Apollo Server from v5.0.0 through v5.3.x.

It also affects all releases of the end-of-life major versions v4, v3, and v2. Although Apollo Server v4 is EOL and Apollo no longer commits to providing support or updates for it, a fix for it was released in v4.13.0. Apollo Server v3 and v2 are no longer updated, as they have been EOL since 2024 and 2023 respectively.

Patches

Patches for this issue are released as @apollo/server versions 5.4.0 and 4.13.0.

In accordance with RFC 7159, these versions now only accept request bodies encoded in UTF-8, UTF-16 (LE or BE), or UTF-32 (LE or BE). Any other character set will be rejected with a 415 Unsupported Media Type error. Note that the more recent JSON RFC, [RFC 8259 (https://datatracker.ietf.org/doc/html/rfc8259#section-8.1), is more strict and will only allow UTF-8. Since this is a minor release, we have chosen to remain compatible with the more permissive RFC 7159 for now. In a future major release, the restriction may be tightened further to only allow UTF-8.

Workarounds

Users of apollo-server v2 or v3 that cannot upgrade for some reason could switch from the standalone apollo-server package to an integration package like apollo-server-express or apollo-server-koa and set up their own server. Please note that these old packages are generally EOL and do not receive any more support or bug fixes. This can only be seen as a short-term workaround. Updating to @apollo/server v5 should be a priority.

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