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

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

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.

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-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

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 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 security community in identifying and improving the performance and security of operation limiting mechanisms.

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

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 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 Documentation

Acknowledgements We appreciate the efforts of the security community in identifying and improving the performance and security of query validation mechanisms.

Summary A vulnerability in Apollo Federation's composition logic allowed some queries to Apollo Router to improperly bypass access controls on types/fields. Apollo Federation incorrectly allowed user-defined access control directives on interface types/fields, which could be bypassed by instead querying the implementing object types/fields in Apollo Router via inline or named fragments. A fix to composition logic in Federation now disallows interfaces types and fields to contain user-defined access control directives.

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. When querying object or interface types/fields, Apollo Router will enforce any directives on those object or interface types/fields, but ignore any directives on interface types/fields they implement. This inconsistent enforcement behavior leads to unexpected runtime security gaps.

Who is impacted This vulnerability impacts Apollo Federation customers defining @authenticated, @requiresScopes, or @policy directives on interface types/fields.

Scope of Impact This vulnerability could allow a malicious actor to craft a query that can bypass access control requirements on the interface types/fields by instead querying them via implementing object types/fields that don't have the same access control requirements via inline or named fragments.

Patches This vulnerability has been fixed in Apollo Federation's composition logic by rejecting user-defined access control directives entirely on interface types and fields (note that access control directives on @interfaceObject fields are not rejected, as those are really specifying requirements on the virtual object fields). Instead, Apollo Federation's composition logic will automatically generate access control directives for interface types/fields in the supergraph schema based on the access control directives on the implementations in subgraph schemas.

Note that this is a breaking change to Apollo Federation, as it no longer allows user-defined access control directives directly on interfaces types and fields. You will need to remove all access control requirements on interface types/fields and manually apply them to each implementing object type/field, where appropriate.

If users are using the Apollo Studio build pipeline with federation version 2.9 or above, then this composition patch version update is automatic and they only need to adjust the access control requirements in your subgraph schemas as mentioned above.

If users are using Apollo Rover for local composition, they will need to update its composition version (after updating Apollo Router, if necessary) to one of the following versions:

- 2.9.5+ - 2.10.4+ - 2.11.5+ - 2.12.1+

Users will then need adjust the access control requirements in your subgraph schemas as mentioned above.

Workarounds - If using Apollo Rover with an unpatched composition version or are using the Apollo Studio build pipeline with Federation version 2.8 or below, users should manually copy the access control requirements on interface types/fields to each implementing object type/field where appropriate. Do not remove those access control requirements from the interface types/fields, as unpatched Apollo Composition will not automatically generate them in the supergraph schema. - Customers not using Apollo Router access control features (@authenticated, @requiresScopes, or @policy directives) or not specifying access control requirements on interface types/fields are not affected and do not need to take action.

Foundry Artifacts was found to be vulnerable to a Denial Of Service attack due to disk being potentially filled up based on an user supplied argument (size).

Secure-upload is a data submission service that validates single-use tokens when accepting submissions to channels. The service only installed on a small number of environments.

Under specific circumstances, privileged users of secure-upload could have selected email templates not necessarily created for their enrollment when sending data upload requests. Authenticated and privileged users of one enrollment could have abused an endpoint to redirect existing submission channels to a dataset they control. An endpoint handling domain validation allowed unauthenticated users to enumerate existing enrollments. Finally, other endpoints allowed enumerating if a resource with a known RID exists across enrollments.

The affected service has been patched with version 0.815.0 and automatically deployed to all Apollo-managed Foundry instances.