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
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
2.11.62.10.52.9.62.12.32.13.2· Vendor fix available
Issue
Impact A vulnerability exists in query plan execution within the gateway that may allow pollution of Object.prototype in certain scenarios. A malicious client may be able to pollute Object.prototype in gateway directly by crafting operations with field aliases and/or variable names that target prototype-inheritable properties. Alternatively, if a subgraph were to be compromised by a malicious actor, they may be able to pollute Object.prototype in gateway by crafting JSON response payloads that target prototype-inheritable properties. Because Object.prototype is shared across the Node.js process, successful exploitation can affect subsequent requests to the gateway instance. This may result in unexpected application behavior, privilege escalation, data integrity issues, or other security impact depending on how polluted properties are subsequently consumed by the application or its dependencies. As of the date of this advisory, Apollo is not aware of any reported exploitation of this…
Recommended action: Upgrade to 2.13.2, 2.12.3, 2.11.6 or 2 more 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 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…
Recommended action: Upgrade to 2.10.1 or later, 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 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…
Recommended action: Upgrade to 2.10.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 2.8.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Versions of @apollo/gateway prior to 0.6.2 are vulnerable to Prototype Pollution. The package uses deepMerge() to merge objects, which may allow attackers to alter the Object prototype through queries with GraphQL aliases. Carefully constructed payloads can override properties of all objects in the application. This may lead to Denial of Service or may be chained with other vulnerabilities leading to Remote Code Execution. Recommendation Upgrade to version 0.6.2 or later.
Recommended action: Upgrade to 0.6.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.