better-auth/oauth-provider CVE-2026-67332

Exploitation requires all of the following to hold simultaneously: (1) the target deployment runs @better-auth/oauth-provider on a stable 1.6.x release or any pre-release before 1.7.0-beta.4; (2) the server is configured with validAudiences containing more than one entry - a single-audience or default-URL-only configuration is explicitly not exploitable for cross-audience escalation; (3) at least one resource server in the allowlist enforces authorization based on the JWT aud claim; and (4) the attacker controls or compromises a registered OAuth client (PR:L - low privilege, but active client registration is required). Exploitation is further limited by the server's own allowlist: a resource not in validAudiences is rejected, so arbitrary resource escalation outside the configured set is not possible. Deployments where resource servers do not consume the aud claim for access control decisions are not practically exploitable even if the spec-compliance gap exists.

The CVSS 4.0 score of 5.3 reflects a network-reachable, low-complexity flaw requiring low-privilege access (PR:L), consistent with the OAuth client credential requirement. The impact metrics show limited confidentiality and integrity effects on both the vulnerable system and subsequent systems (VC:L/VI:L/SC:L/SI:L), which aligns with the constrained blast radius: exploitation is bounded by the server's validAudiences allowlist, and single-audience deployments are explicitly non-exploitable. No EPSS data was provided in the input, and the vulnerability is not listed in the CISA KEV catalog, indicating no confirmed widespread active exploitation. The vendor advisory explicitly scopes the vulnerability to deployments with more than one validAudiences entry whose resource servers consume the aud claim for authorization decisions - a non-default, opt-in configuration - which materially reduces the real-world risk population below what the CVSS vector alone suggests. The stable 1.6.x release line remains unpatched, meaning organizations on stable releases must apply workarounds rather than a routine upgrade. Overall this is a genuine authorization boundary violation with moderate priority for multi-audience OAuth deployments, but lower urgency for typical single-audience or non-aud-enforcing configurations.

A malicious OAuth client registered with the authorization server completes a legitimate authorization code flow scoped to Resource Server A. At the token endpoint, the client then specifies resource=https://resource-server-b.example.com - a different server listed in validAudiences - and receives a signed JWT whose aud claim names Resource Server B, despite the authorization grant never covering it. The client presents this token to Resource Server B, which trusts the aud claim and grants access to data or operations the authorization never permitted. No public exploit code has been identified at time of analysis.