6.8

CVSS Score

3.1

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

GHSA-x445-f3h2-j279

GHSA-x445-f3h2-j279: Auth.js: OAuth state, nonce, and PKCE check cookies are not bound to the provider that created them

Summary

Auth.js stores the OAuth/OIDC anti-CSRF checks (state, nonce, and the PKCE verifier) in global cookies that are not bound to the provider that created them. On callback, a check value minted during a sign-in started with one provider can satisfy the callback for a different provider, because the stored cookie is not verified against the callback provider's identity (provider id, issuer, client id, or redirect URI). In a multi-provider app that allows account linking while logged in, this provider-confusion / mix-up condition can let an attacker link their account at a second provider to a victim's user.

Am I affected?

You may be affected if all of the following hold:

You use next-auth <= 4.24.14 or >= 5.0.0-beta.1, <= 5.0.0-beta.31, or @auth/core <= 0.41.2.
You configure multiple OAuth/OIDC providers.
You allow users to link additional providers while logged in.
At least one configured provider's authorization request is observable by an attacker, and at least one target provider's callback can be satisfied without a PKCE verifier (i.e. it relies only on state or only on nonce).

You are not affected if you use a single OAuth provider, do not allow logged-in account linking, or all providers enforce PKCE.

Impact

Account-linking confusion: an attacker can get their account at a target provider linked to the victim's Auth.js user, granting the attacker persistent sign-in to the victim's account through that linked provider.
Exploitation requires luring the victim into starting a legitimate same-origin flow; it cannot be performed by cross-site request forgery alone, which reduces practical likelihood.

Patched version

The fix binds the OAuth check cookies to the provider/authorization flow that created them, so a callback cannot consume a check value minted for a different provider. Upgrade to the first releases containing this fix (pending; this advisory will be updated with exact patched versions before publication).

Miggo Vulnerability Database

→

GHSA-x445-f3h2-j279

GHSA-x445-f3h2-j279:

6.8

CVSS Score

3.1

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
@auth/core	npm	<= 0.41.2	0.41.3
next-auth	npm	>= 5.0.0-beta.1, <= 5.0.0-beta.31	5.0.0-beta.32
next-auth	npm	<= 4.24.14	4.24.15

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The vulnerability exists because the OAuth anti-CSRF cookies (state, nonce, and PKCE verifier) were not bound to the specific OAuth provider that initiated the authentication flow. The cookies were stored globally, meaning a cookie generated during a sign-in attempt with one provider could be used in the callback of a different provider. This could lead to a provider-confusion or mix-up attack.

The patches address this by adding the provider.id to the cookie's payload when it is created (in signCookie for next-auth and sealCookie for @auth/core). Subsequently, when the cookie is consumed (in pkce.use, state.use, nonce.use for next-auth and parseCookie for @auth/core), a check is added to ensure the provider.id in the cookie matches the ID of the provider handling the callback. If they do not match, an error is thrown, preventing the attack.

The identified vulnerable functions are the ones responsible for consuming and validating these cookies, as they were missing the crucial provider verification step. An attacker could exploit this by tricking a user into initiating an authentication flow with a malicious or compromised provider, capturing the anti-CSRF cookie, and then using it to link their own account to the victim's account on a different, legitimate provider within the same application.

Vulnerable functions

pkce.use

packages/next-auth/src/core/lib/oauth/checks.ts

The `pkce.use` function is vulnerable because it did not verify that the PKCE cookie was created by the same provider that is handling the callback. This allowed an attacker to use a PKCE cookie from one provider to bypass checks for another provider.

state.use

packages/next-auth/src/core/lib/oauth/checks.ts

The `state.use` function is vulnerable because it did not verify that the state cookie was created by the same provider that is handling the callback. This allowed an attacker to use a state cookie from one provider to bypass CSRF checks for another provider, leading to account linking vulnerabilities.

nonce.use

packages/next-auth/src/core/lib/oauth/checks.ts

The `nonce.use` function is vulnerable because it did not verify that the nonce cookie was created by the same provider that is handling the callback. This allowed an attacker to use a nonce cookie from one provider to bypass replay attack protections for another provider.

parseCookie

packages/core/src/lib/actions/callback/oauth/checks.ts

The `parseCookie` function in `@auth/core` is vulnerable because it did not validate that the provider that created the cookie is the same one handling the callback. This allowed for provider-confusion attacks where a cookie from one provider could be used for another.