NextAuth.js: OAuth state, nonce, and PKCE check cookies are not bound to the provider that created them

CISA KEV lists vulnerabilities known to be exploited. FIRST EPSS estimates the likelihood of exploitation in the next 30 days. An unavailable score does not mean zero risk.

No exploitation or prediction data is available here for these CVEs. This does not mean they are safe or unlikely to be exploited.

NextAuth.js provides authentication for Next.js. Prior to@auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32, 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, including the provider ID, issuer, client ID, or redirect URI. In a multi-provider application that permits account linking while logged in, when one provider's authorization request is observable and a target provider callback can be satisfied without a PKCE verifier, an attacker can lure a victim into starting a legitimate same-origin flow and link the attacker's target-provider account to the victim's Auth.js user. The linked provider grants the attacker persistent sign-in to the victim's account, while cross-site request forgery alone is insufficient. This issue is fixed in @auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32.

Source published

12 Aug 2026 20:23:39 UTC

Source modified

13 Aug 2026 15:32:15 UTC

Saved here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

Source: cve-program · CVE Program Terms of Use. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS 3.1 · 6.8 CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N

NextAuth.js provides authentication for Next.js. Prior to@auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32, 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, including the provider ID, issuer, client ID, or redirect URI. In a multi-provider application that permits account linking while logged in, when one provider's authorization request is observable and a target provider callback can be satisfied without a PKCE verifier, an attacker can lure a victim into starting a legitimate same-origin flow and link the attacker's target-provider account to the victim's Auth.js user. The linked provider grants the attacker persistent sign-in to the victim's account, while cross-site request forgery alone is insufficient. This issue is fixed in @auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32.

Source published

Aug 12, 2026, 8:23:39 PM (timezone not stated)

Source modified

Aug 13, 2026, 3:32:15 PM (timezone not stated)

Saved here

14 Nov 2026 03:06:47 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

Source: euvd · ENISA EUVD · source terms and attribution apply. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

EUVD CVSS 3.1 · 6.8 CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N

NextAuth.js provides authentication for Next.js. Prior to@auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32, 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, including the provider ID, issuer, client ID, or redirect URI. In a multi-provider application that permits account linking while logged in, when one provider's authorization request is observable and a target provider callback can be satisfied without a PKCE verifier, an attacker can lure a victim into starting a legitimate same-origin flow and link the attacker's target-provider account to the victim's Auth.js user. The linked provider grants the attacker persistent sign-in to the victim's account, while cross-site request forgery alone is insufficient. This issue is fixed in @auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32.

Source published

12 Aug 2026 21:17:41 UTC

Source modified

9 Sep 2026 20:58:37 UTC

Saved here

25 Oct 2026 15:19:09 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

Source: nvd · NIST NVD usage terms; underlying source attribution retained. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS 3.1 · [email protected] · Secondary · 6.8 CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N

## 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). ## Workarounds If you cannot upgrade immediately: - Enable PKCE (`checks: ["pkce"]`, in addition to `state`/`nonce`) on every provider that supports it; PKCE blocks the practical code-swap variant because the attacker cannot observe the relying party's verifier. - Avoid offering logged-in account linking across multiple providers where one provider is lower-trust or attacker-observable. - Treat `events.linkAccount` as sensitive: add audit logging, user notification, or out-of-band confirmation so that any unexpected link is visible (defense-in-depth, not a root-cause fix). ## Credit Reported by @Nadav0077. Thank you for the responsible disclosure.

Source published

23 Jul 2026 14:31:51 UTC

Source modified

10 Sep 2026 03:50:53 UTC

Saved here

24 Oct 2026 13:17:17 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

Source: osv · GitHub Advisory Database · CC-BY-4.0. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS_V3 · CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N

Publisher rating · MODERATE