GHSA-G8JH-VG5J-4H3F
Vulnerability from github – Published: 2025-11-06 15:45 – Updated: 2025-11-07 20:31Summary
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 directives that were renamed in this way.
Who Is Impacted
This vulnerability impacts Apollo Router customers defining @authenticated, @requiresScopes, or @policy directives on schema elements that were renamed via @link imports are impacted.
Scope of Impact
The vulnerability could allow a malicious actor to craft a query that can bypass access control requirements on schema elements protected by renamed access control directives.
Patches
This vulnerability has been fixed in Apollo Router by updating the access control logic to handle the imports argument in @link directives. You will need to update Router to one of the following versions:
- 1.61.12+
- 2.8.1+
Workarounds
- If you are not immediately updating Router to a patched version, you should remove any renames of access control directives in the
importsargument to the@linkdirective. - Customers not using Apollo Router with renamed access control directives (
@authenticated,@requiresScopes, and@policy) are not affected and do not need to take action.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "apollo-router"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.61.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "apollo-router"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0-alpha.0"
},
{
"fixed": "2.8.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-64347"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-06T15:45:34Z",
"nvd_published_at": "2025-11-07T18:15:37Z",
"severity": "HIGH"
},
"details": "# Summary \nA 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.\n\n## Details\n\nApollo 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](https://www.apollographql.com/docs/graphos/schema-design/federated-schemas/reference/directives#renaming-directives), which can be useful if their default names match an existing user-defined directive in their subgraph schema. However, Apollo Router\u0027s access control logic ignored the `imports` argument, and would accordingly ignore access control directives that were renamed in this way.\n\n## Who Is Impacted\n\nThis vulnerability impacts Apollo Router customers defining `@authenticated`, `@requiresScopes`, or `@policy` directives on schema elements that were renamed via `@link` imports are impacted.\n\n### Scope of Impact\n\nThe vulnerability could allow a malicious actor to craft a query that can bypass access control requirements on schema elements protected by renamed access control directives.\n\n## Patches\n\nThis vulnerability has been fixed in Apollo Router by updating the access control logic to handle the `imports` argument in `@link` directives. You will need to update Router to one of the following versions:\n\n- 1.61.12+\n- 2.8.1+\n\n## Workarounds\n\n- If you are not immediately updating Router to a patched version, you should remove any renames of access control directives in the `imports` argument to the `@link` directive.\n- Customers not using Apollo Router with renamed access control directives (`@authenticated`, `@requiresScopes`, and `@policy`) are not affected and do not need to take action.",
"id": "GHSA-g8jh-vg5j-4h3f",
"modified": "2025-11-07T20:31:54Z",
"published": "2025-11-06T15:45:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/apollographql/router/security/advisories/GHSA-g8jh-vg5j-4h3f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64347"
},
{
"type": "WEB",
"url": "https://github.com/apollographql/router/commit/78e4b20a2fc26cc5f141aa47992ed85375266a2b"
},
{
"type": "PACKAGE",
"url": "https://github.com/apollographql/router"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Apollo Router Improperly Enforces Renamed Access Control Directives"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.