Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
13 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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…
Recommended action: Upgrade to 2.12.1, 2.10.2 or 1.61.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.…
Recommended action: Upgrade to 2.8.1 or 1.61.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2.8.1 or 1.61.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2.1.1 or 1.61.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2.1.1 or 1.61.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2.1.1 or 1.61.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.…
Recommended action: Upgrade to 2.1.1 or 1.61.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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…
Recommended action: Upgrade to 1.52.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 1.52.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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…
Recommended action: Upgrade to 1.45.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.40.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: Or you can disable defer and subscriptions support: and continue to use the coprocessor supergraph response. References https://github.com/apollographql/router/issues/4013
Recommended action: Upgrade to 1.33.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.…
Recommended action: Upgrade to 1.29.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.