GHSA-p2fr-6hmx-4528: @better-auth/oauth-provider may provide access tokens for unauthorized audiences via unbound resource indicators
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.
AI Analysis
Technical 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.
Potential 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.
Mitigation Recommendations
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. Until the fix is applied, do not rely on the resource indicator as a secure authorization boundary.
GHSA-p2fr-6hmx-4528: @better-auth/oauth-provider may provide access tokens for unauthorized audiences via unbound resource indicators
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.
CVSS v3.1
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
@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.
Potential 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.
Mitigation Recommendations
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. Until the fix is applied, do not rely on the resource indicator as a secure authorization boundary.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-p2fr-6hmx-4528
- Osv Schema Version
- 1.4.0
- Aliases
- []
- Ecosystems
- ["npm"]
- Database Specific Severity
- MODERATE
- Cvss Version
- 3.1
Threat ID: 6a4e4ef9c9d9e3dbe328cf1b
Added to database: 07/08/2026, 13:22:01 UTC
Last enriched: 07/08/2026, 13:45:18 UTC
Last updated: 07/08/2026, 13:45:18 UTC
Views: 2
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
External Links
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.