VulnerabilityPublished 7 Jul 2026

@better-auth/oauth-provider may provide access tokens for unauthorized audiences via unbound resource indicators

Affects @better-auth/oauth-providerSource GCVE Database

CVSS 6.4 Medium : upgrade to 1.7.0-beta.4 when convenient.

Data as of 8 Jul 2026, 13:45 UTC

CVSS 3.1 base score

6.4Medium

How severe the flaw is on the 0–10 CVSS scale.

Patch: Available – fixed in 1.7.0-beta.4

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N

Attack Vector: Network
Attack Complexity: Low
Privileges Required: Low
User Interaction: None
Scope: Changed
Confidentiality: Low
Integrity: Low
Availability: None

Bold values are the worst case: easiest to exploit or largest impact.

Attack Vector: Network: The vulnerable component is bound to the network stack and the set of possible attackers extends beyond the other options listed, up to and including the entire Internet. Such a vulnerability is often termed 'remotely exploitable' and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers).
Attack Complexity: Low: Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component.
Privileges Required: Low: The attacker is authorized with (i.e., requires) privileges that provide basic user capabilities that could normally affect only settings and files owned by a user. Alternatively, an attacker with Low privileges may have the ability to cause an impact only to non-sensitive resources.
User Interaction: None: The vulnerable system can be exploited without any interaction from any user.
Scope: Changed: An exploited vulnerability can affect resources beyond the security scope managed by the security authority of the vulnerable component. In this case, the vulnerable component and the impacted component are different and managed by different security authorities.
Confidentiality: Low: There is some loss of confidentiality. Access to some restricted information is obtained, but the attacker does not have control over what information is obtained, or the amount or kind of loss is limited. The information disclosure does not cause a direct, serious loss to the impacted component.
Integrity: Low: Modification of data is possible, but the attacker does not have control over the consequence of a modification, or the amount of modification is limited. The data modification does not have a direct, serious impact on the impacted component.
Availability: None: There is no impact to availability within the impacted component.

Definitions: FIRST CVSS v3.1 specification.

What to do

Upgrade @better-auth/oauth-provider to 1.7.0-beta.4.

Affected software

Product	Affected	Fixed in
npm@better-auth/oauth-provider	Affected >=1.4.8 <1.7.0-beta.4	Fixed in 1.7.0-beta.4

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

A fix is available in @better-auth/oauth-provider version 1.7.0-beta.4 and later (including 1.7.0). Upgrading to these versions and running the required schema migration (e.g., via 'npx auth migrate') resolves the issue by binding resources to authorization grants and enforcing audience restrictions. The stable 1.6.x line is not patched. If upgrading is not possible, developers should limit 'validAudiences' to a single audience or the default base URL to prevent cross-audience token issuance. Additionally, resource servers should be configured to accept tokens only when the audience exactly matches their identifier and reject tokens with multiple audiences. If you cannot patch yet, do not rely on the resource indicator as a secure authorization boundary.

Description

The @better-auth/oauth-provider package versions in the stable 1.6.x line and pre-releases before 1.7.0-beta.4 allow OAuth clients to request access tokens for audiences (resources) that were not authorized during the initial authorization flow. This occurs because the provider does not bind the requested resource at the authorization endpoint to the token issuance, enabling clients to obtain tokens for any resource in the server's allowlist. The issue affects deployments that configure multiple valid audiences and rely on the audience claim for authorization decisions. The vulnerability is fixed in version 1.7.0-beta.4 and later, which enforce binding of resources to the authorization grant and restrict token issuance accordingly. Workarounds include limiting valid audiences to a single entry and configuring resource servers to reject tokens with unexpected audiences.

Impact

An attacker who completes an OAuth flow for a registered client can obtain access tokens targeting resource servers that the user's authorization did not cover, provided those resources are in the server's allowlist. Resource servers that enforce authorization based on the audience claim may accept tokens for unintended resources, potentially allowing unauthorized access within the scope of the granted permissions. The vulnerability does not elevate scopes or privileges but allows cross-audience token usage, which may lead to unauthorized access to data or operations on other resource servers.

Summary

@better-auth/oauth-provider versions stable 1.6.x and pre-1.7.0-beta.4 allow OAuth clients to specify the access token audience via the RFC 8707 resource parameter at the token endpoint without binding this choice to the original authorization grant. The provider validates requested resources only against a server-wide allowlist but does not record or constrain the resource at authorization or refresh token issuance. Consequently, a client can obtain a JWT access token for a resource server not covered by the user's authorization, as long as the resource is in the allowlist. This behavior diverges from RFC 8707, which requires the authorization server to record and restrict resources to those authorized initially. The fix in 1.7.0-beta.4 records requested resources at authorization, enforces narrowing at token issuance, retains resource binding across refresh tokens, and changes token claims and schema requiring migration. The stable 1.6.x line is not patched.

CWE-285Improper Authorization (opens in a new tab)
Class weaknessLikelihood of exploit: HighOWASP Top 10 A01:2025: Broken Access Control (opens in a new tab)
The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.
MITRE discourages mapping vulnerabilities to this broad entry; the root cause is usually a more specific weakness.
Architecture and Design
Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) to enforce the roles at the appropriate boundaries.
Architecture and Design
Ensure that you perform access control checks related to your business logic. These checks may be different than the access control checks that you apply to more generic resources such as files, connections, processes, memory, and database records.
Architecture and Design · Libraries or Frameworks
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
OWASP Cheat Sheets
Authorization (opens in a new tab)
OWASP ASVS 4.0.3
V8.3.8 (opens in a new tab)
V13.4.2 (opens in a new tab)
V7.2.2 (opens in a new tab)
Attack patterns
Accessing Functionality Not Properly Constrained by ACLs (opens in a new tab)
Cross Zone Scripting (opens in a new tab)
Directory Indexing (opens in a new tab)
Subverting Environment Variable Values (opens in a new tab)
Using Malicious Files (opens in a new tab)
From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).
CWE-863Incorrect Authorization (opens in a new tab)
Class weaknessLikelihood of exploit: HighCWE Top 25 (2025): #17OWASP Top 10 A01:2025: Broken Access Control (opens in a new tab)
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
Architecture and Design
Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) to enforce the roles at the appropriate boundaries.
Architecture and Design
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records.
Architecture and Design · Libraries or Frameworks
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
OWASP Cheat Sheets
Authorization (opens in a new tab)
OWASP ASVS 4.0.3
V8.3.8 (opens in a new tab)
V13.4.2 (opens in a new tab)
V7.2.2 (opens in a new tab)
From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).

References

Community reviews

Loading reviews…

What to do

Affected software

Description

AI analysisMachine-generated, updated 8 Jul 2026, 13:45 UTC

WeaknessesCWE-285, CWE-863

Technical details

References

Community reviews

Related threats