GHSA-p2fr-6hmx-4528: Unbound Resource Indicators Allow Cross-Audience Access Token Escalation in @better-auth/oauth-provider

The @better-auth/oauth-provider package, a component of the better-auth authentication framework, contains an authorization bypass flaw. The issue is located in the implementation of the RFC 8707 (Resource Indicators for OAuth 2.0) specification.

In a multi-resource server architecture, the authorization server must strictly limit the audience of an access token to the specific resources authorized by the user. Under RFC 8707, clients specify their target resource server via a resource query parameter during the authorization phase. The authorization server must capture this state and bind it to the resulting authorization grant.

Because the provider fails to persist the resource constraints between the authorization phase and the token exchange phase, clients can request access to any resource in the server configuration. The threat surface includes lateral access escalation across internal microservices and unauthorized access to downstream resource servers.

The core technical flaw stems from the complete decoupling of the authorization request parameter processing and the token generation logic. The provider ignores the resource parameter at the authorization endpoint (/oauth2/authorize). Because of this, the consent screens presented to the resource owner do not accurately reflect the specific resource servers the client will ultimately access.

Furthermore, the database schemas for authorization codes and refresh tokens lack fields to store stateful resource constraints. When an authorization code is successfully issued, it contains no reference to the resources that the user approved. This violates RFC 8707 Section 2.2, which dictates that the authorization server must record the authorized resources and ensure the subsequent token requests represent a subset of that initial grant.

When the client interacts with the /oauth2/token endpoint, the token generator reads the resource parameter directly from the request body. Instead of verifying this parameter against the authorization code's bound resource, the server evaluates it against a global config array called validAudiences. If the target is present in this global list, the server mints a JWT containing the target in the aud (audience) claim, completing the unauthorized access escalation.

To understand the implementation flaw, examine the conceptual behavior of the token exchange handler and database interaction. The vulnerable state persists because the data layer does not support multi-resource tracking.

Below is a representation of the vulnerable code pattern contrasted with the patched statefulness:

// Vulnerable Token Endpoint Logic
async function handleTokenExchange(req) {
  const codeRecord = await db.findAuthCode(req.code);
  const requestedResource = req.resource; // Obtained directly from the POST body
 
  if (requestedResource) {
    // BUG: The codeRecord has no 'resources' property. 
    // The check is performed globally, ignoring user-authorized boundaries.
    if (!config.validAudiences.includes(requestedResource)) {
      throw new OAuthError("invalid_target", "Resource not in global allowlist");
    }
  }
 
  // Access token is minted for the arbitrary resource requested
  return generateAccessToken({
    sub: codeRecord.userId,
    audience: requestedResource || config.defaultAudience
  });
}

The fix implements structural changes to store the approved resources into the database. When the /oauth2/token endpoint is queried, validation is performed directly against the database record instead of the global configuration.

// Patched Token Endpoint Logic
async function handleTokenExchange(req) {
  const codeRecord = await db.findAuthCode(req.code); // Now retrieves stateful 'resources' array
  const requestedResource = req.resource;
 
  if (requestedResource) {
    // FIX: Verify the requested resource is a subset of the authorized resources
    if (!codeRecord.resources.includes(requestedResource)) {
      throw new OAuthError("invalid_target", "The requested resource is not authorized for this grant");
    }
  }
 
  return generateAccessToken({
    sub: codeRecord.userId,
    audience: requestedResource
  });
}

Exploitation of this vulnerability requires the target authorization server to configure multiple resources inside the validAudiences array. No custom exploitation tools are required, as standard OAuth library clients or command-line HTTP clients can trigger the flaw.

An attacker controls a registered OAuth client. The target server has configured https://api.billing.example.com (sensitive) and https://api.stats.example.com (public) in its global allowlist. The attacker initiates the standard authorization flow targeting the public API.

After obtaining the authorization code, the client sends a token request to /oauth2/token but overrides the resource field to point to the sensitive billing API. Because there is no check linking the code to the initial scope, the server returns an access token possessing an audience claim (aud) set to the sensitive billing system.

POST /oauth2/token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded
 
grant_type=authorization_code&
code=AUTHORIZATION_CODE_HERE&
redirect_uri=https://client.example.com/callback&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET&
resource=https://api.billing.example.com

The same technique applies to refresh token grants. If a client possesses a valid refresh token, it can issue a refresh request with a modified resource parameter, pivoting its audience access to any target server inside the validAudiences array without prompting the user for consent.

This vulnerability breaks the security boundaries enforced by OAuth consent screens. While the authorization server attempts to maintain a list of valid audiences via configuration, the failure to bind those audiences to specific authorization transactions compromises the isolation of multi-tenant or multi-resource API environments.

If the authorization server is used to authenticate users across both low-security and high-security internal services, any client compromised by an attacker can escalate access tokens to gain privileges on the high-security APIs. This bypasses the zero-trust principle where resource servers rely on the correctness of the token audience claim to deny access to unauthorized clients.

From a CVSS perspective, the vulnerability is classified as Medium (6.4). The attack complexity is low, and no user interaction is required after the initial login. However, the scope of impact changes (Scope: Changed) because the failure allows the client to gain unauthorized privileges on external downstream systems (the resource servers).

The definitive solution is to upgrade to @better-auth/oauth-provider@1.7.0 (or @better-auth/oauth-provider@1.7.0-beta.4). The updated release implements stateful database storage for resource lists and enforces strict subset checks during token exchanges.

Because the patch introduces database schema modifications to track authorized resource boundaries, running migrations is mandatory. Administrators must run the database migration utilities to apply the structural changes.

npx auth migrate

For environments where upgrading is not immediately possible, implement the following workarounds:

1. Limit the validAudiences configuration array to a single, global entry. When only one resource is allowed, cross-resource escalation becomes impossible.
2. Configure downstream resource servers to strictly validate that incoming tokens contain only their specific audience identifier and do not support broad, multi-audience arrays.
3. Implement a custom validation interceptor on the /oauth2/token endpoint to block requests containing a resource parameter that differs from the default client authorization parameters.