Summary
@better-auth/oauth-provider may provide access tokens for unauthorized audiences via unbound resource indicators
Full technical description
Am I affected?
Users are affected if all of the following hold:
- Their application depends on
@better-auth/oauth-provideron any stable1.6.xrelease (the stable line is not patched) or on a pre-release before1.7.0-beta.4. - Their application either configures validAudiences
with more than one audience, or it issues JWT access tokens whoseaud` (resource) claim is consumed by their resource servers. - Their resource servers make authorization decisions based on that
audor resource value.
A deployment with a single validAudiences entry (or the default, their server's base URL) cannot mint a token for a different audience. The provider rejects any resource outside the allowlist. Such a deployment still does not bind the resource to the authorization grant, so the spec-compliance gap remains even where cross-audience escalation does not apply.
Fix:
- Upgrade to
@better-auth/[email protected](then1.7.0), then run the schema migration (npx auth migrate). This is a breaking change: a token or refresh request may only narrow the authorizedresource, an uncovered resource returnsinvalid_target, andcustomAccessTokenClaimsreceives aresourcesarray in place ofresource. - The
1.6.xstable line is not patched. If an application stays on it, developers should apply the workarounds below.
@better-auth/oauth-provider lets an OAuth client choose the access-token audience through the RFC 8707 resource parameter at the token endpoint. It does not bind that choice to the authorization grant. A client that completes a normal authorization flow can request a JWT access token whose audience targets a resource server the authorization never covered. The only constraint is that the resource appears in the server's validAudiences allowlist. The same gap applies to the refresh grant: a refresh token issued in a flow targeting one resource can be redeemed for an access token bound to a different allow-listed resource.
Details
The provider accepts resource only at the token endpoint, never at the authorization endpoint. At /oauth2/token it validates each requested resource against the server-wide validAudiences allowlist and writes the result into the JWT aud claim. It does not record the requested resources on the authorization code, and it does not store them on the refresh-token row.
Two consequences follow. For the authorization-code grant, the resource a client states at /oauth2/authorize is discarded, and the resource it sends at /oauth2/token is honored on its own, checked only against the allowlist. For the refresh grant, the audience is re-derived from the refresh request body alone, because no resource from the original grant is retained to constrain it. In both cases the audience becomes a per-request, client-chosen value rather than a property of the authorization.
This diverges from RFC 8707. The specification expects the authorization server to record the resources requested at authorization, then let the token endpoint narrow them but never widen them. A refresh token should stay bound to the resources of the original grant.
Workarounds
If developers cannot upgrade their applications:
- Set
validAudiencesto a single audience, or leave it unset so it defaults to their application's base URL. The provider then rejects any other requested resource, which removes cross-audience selection. - Configure each resource server to accept a token only when its own identifier is the expected audience, and to reject tokens whose
audis an array that also lists other audiences. - Do not rely on the
resourceindicator as an authorization boundary until developers run a release that contains the fix.
Credit
Reported and fixed by @dvanmali.
Resources
- RFC 8707, "Resource Indicators for OAuth 2.0", Section 2.2 "Access Token Request": https://www.rfc-editor.org/rfc/rfc8707#section-2.2
- RFC 9068, "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", Section 2.2 "Data Structure": https://www.rfc-editor.org/rfc/rfc9068#section-2.2
- CWE-863, "Incorrect Authorization": https://cwe.mitre.org/data/definitions/863.html
- CWE-285, "Improper Authorization": https://cwe.mitre.org/data/definitions/285.html
Impact
An attacker who can complete an OAuth flow for a registered client can obtain an access token whose audience points at a resource server that the user's authorization never covered. Where resource servers enforce the aud or resource value for authorization, a token granted for one resource becomes usable at another. The reachable data and operations stay limited to the scopes granted to that client, since the provider checks scopes independently of the resource.
The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions. Typical impact: unauthorized data access or execution of privileged operations.
GHSA-P2FR-6HMX-4528 has a CVSS score of 6.4 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.7.0-beta.4); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Fixed in @better-auth/[email protected] (then 1.7.0). The fix records the requested resources at authorization, stores them with the authorization code, enforces subset narrowing at the token endpoint, retains the original resource set across refresh, and exposes aud at introspection. The 1.6.x stable line is not patched.
The fix is a breaking change. It replaces customAccessTokenClaims.resource with a resources array, returns invalid_target for a resource the authorization did not cover, and adds a schema field that requires a migration. After upgrading, run npx auth migrate (or npx auth generate if developers manage the schema themselves).
Frequently Asked Questions
- What is GHSA-P2FR-6HMX-4528? GHSA-P2FR-6HMX-4528 is a medium-severity incorrect authorization vulnerability in @better-auth/oauth-provider (npm), affecting versions >= 1.4.8, < 1.7.0-beta.4. It is fixed in 1.7.0-beta.4. The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions.
- How severe is GHSA-P2FR-6HMX-4528? GHSA-P2FR-6HMX-4528 has a CVSS score of 6.4 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of @better-auth/oauth-provider are affected by GHSA-P2FR-6HMX-4528? @better-auth/oauth-provider (npm) versions >= 1.4.8, < 1.7.0-beta.4 is affected.
- Is there a fix for GHSA-P2FR-6HMX-4528? Yes. GHSA-P2FR-6HMX-4528 is fixed in 1.7.0-beta.4. Upgrade to this version or later.
- Is GHSA-P2FR-6HMX-4528 exploitable, and should I be worried? Whether GHSA-P2FR-6HMX-4528 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-P2FR-6HMX-4528 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-P2FR-6HMX-4528? Upgrade
@better-auth/oauth-providerto 1.7.0-beta.4 or later.