CVE-2025-64530: Apollo Federation Auth Bypass Vulnerability

CVE-2025-64530 Overview

CVE-2025-64530 is an authorization bypass vulnerability in Apollo Federation's composition logic. Apollo Federation is an architecture for declaratively composing APIs into a unified GraphQL graph. The flaw allows queries sent to Apollo Router to bypass user-defined access control directives applied to interface types and fields. Attackers can query the implementing object types or fields directly using inline fragments to evade @authenticated, @requiresScopes, and @policy directives. The vulnerability affects all Apollo Federation composition versions before 2.9.5, 2.10.4, 2.11.5, and 2.12.1. It maps to [CWE-288: Authentication Bypass Using an Alternate Path or Channel].

Critical Impact
Unauthenticated remote attackers can bypass GraphQL access controls and read protected data exposed through interface types in supergraph schemas.

Affected Products

Apollo Federation composition logic versions prior to 2.9.5
Apollo Federation composition logic versions prior to 2.10.4 and 2.11.5
Apollo Federation composition logic versions prior to 2.12.1, including Apollo Rover and Apollo Studio build pipelines using Federation 2.8 or below

Discovery Timeline

2025-11-13 - CVE-2025-64530 published to NVD
2026-04-15 - Last updated in NVD database

Technical Details for CVE-2025-64530

Vulnerability Analysis

The vulnerability exists in Apollo Federation composition logic. Composition incorrectly accepts user-defined access control directives on GraphQL interface types and fields. When the supergraph schema is generated, those access control requirements are not propagated to the implementing object types or fields. Apollo Router enforces directives only where they appear in the composed schema. Clients that query the implementing object types directly, such as through inline fragments, receive data without the intended authorization checks.

The defective behavior affects deployments using @authenticated, @requiresScopes, or @policy directives. Schemas that place these directives only on interface declarations are exposed. Confidentiality of fields intended to be gated by authentication or scope checks is broken, while integrity and availability are not directly affected.

Root Cause

The root cause is a logical flaw in composition: interface-level access control directives are silently dropped rather than copied to all implementing types or rejected at composition time. This creates an inconsistency between the developer's intent and the runtime enforcement performed by Apollo Router. The fix changes composition to disallow access control directives on interfaces and fields entirely, forcing developers to declare them on concrete types where Router can enforce them.

Attack Vector

An unauthenticated remote attacker sends a GraphQL query to the Apollo Router endpoint. Instead of selecting a protected field through the interface type, the attacker uses an inline fragment such as ... on ConcreteType { protectedField } to address the implementing object directly. Because the composed supergraph contains no directive on the concrete type, Router returns the data without evaluating the auth, scope, or policy requirement defined on the interface. No prior privileges or user interaction are required.

Detection Methods for CVE-2025-64530

Indicators of Compromise

GraphQL operations targeting implementing object types with inline fragments that retrieve fields normally protected by interface-level directives
Successful responses to anonymous or low-privilege clients for fields documented as requiring authentication or specific scopes
Apollo Router access logs lacking authorization decision events for queries that touch sensitive data

Detection Strategies

Audit your Federation supergraph schema for any @authenticated, @requiresScopes, or @policy directives applied to interface types or interface fields
Run composition with a patched Federation version and review composition errors that flag previously accepted interface-level directives
Compare query traces in Apollo Router with expected authorization outcomes for protected interface fields

Monitoring Recommendations

Enable verbose Apollo Router telemetry for authorization decisions and forward logs to a centralized analytics platform
Alert on GraphQL queries that use inline fragments against types containing fields previously gated by interface directives
Track anomalous read volumes from unauthenticated sessions against fields linked to protected interfaces

How to Mitigate CVE-2025-64530

Immediate Actions Required

Upgrade Apollo Federation composition to 2.9.5, 2.10.4, 2.11.5, or 2.12.1 or later, depending on the minor branch in use
Recompose and redeploy the supergraph schema to Apollo Router after upgrading composition
Inventory all interface types and fields that carry @authenticated, @requiresScopes, or @policy directives and remediate before redeploying

Patch Information

The Apollo team released fixes in Apollo Federation composition versions 2.9.5, 2.10.4, 2.11.5, and 2.12.1. The patched composition logic disallows user-defined access control directives on interface types and fields, forcing developers to declare them on implementing object types where Apollo Router enforces them. See the Apollo Federation GitHub Security Advisory GHSA-mx7m-j9xf-62hw for full details.

Workarounds

Manually copy each interface-level access control requirement onto every implementing object type and field in the schema
Do not remove the directives from interface types until composition is upgraded, because unpatched composition will not regenerate them in the supergraph
Customers not using @authenticated, @requiresScopes, or @policy, or not placing them on interface types or fields, are not affected and require no action

bash

# Example: move interface-level auth directive onto implementing types
# Before (vulnerable):
# interface Node @authenticated { id: ID! }
# type User implements Node { id: ID! name: String }
#
# After (mitigated):
# interface Node { id: ID! }
# type User implements Node @authenticated { id: ID! @authenticated name: String }