chore(deps): update dependency @apollo/gateway to v2.10.1 [security] (lts)

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
@apollo/gateway (source)	2.10.0 -> 2.10.1

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

GitHub Vulnerability Alerts

CVE-2025-32031

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.

CVE-2025-32030

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.

---

Release Notes

apollographql/federation (@​apollo/gateway)

v2.10.1

Compare Source

---

Configuration

📅 Schedule: Branch creation - "" in timezone Europe/London, Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[changeset-bot]

⚠️ No Changeset found

Latest commit: e40a4df

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR