The vulnerability exists in Apollo Router's authorization logic, specifically in how it handles access control directives (@authenticated, @requiresScopes, @policy) that are renamed using the import argument of the @link directive. The root cause lies in the apollo_router::spec::schema::Schema::directive_name and apollo_router::spec::schema::Schema::has_spec functions. These functions contained flawed logic that manually parsed @link directive URLs and only accounted for renaming via the as argument, completely ignoring the import argument which is used for renaming individual directives.
When a GraphQL query is processed, the router's authorization plugin creates 'visitor' objects (e.g., AuthenticatedVisitor, PolicyFilteringVisitor) to traverse the query and schema, enforcing the declared access controls. The constructors for these visitors, such as AuthenticatedVisitor::new, call Schema::directive_name to determine the correct name of the authorization directive to enforce. Because the vulnerable directive_name function would return the default directive name instead of the renamed one, the visitors would fail to find the directive on the schema elements, and consequently, no access control would be enforced. This allows an attacker to craft queries that bypass authorization checks for any data protected by a renamed directive.
The patch rectifies this by removing the faulty manual parsing logic and instead utilizing the apollo-federation crate, which correctly interprets the full semantics of the @link directive, including the import argument. This ensures that the authorization system is always aware of the correct directive names, even when they are renamed.