CVE-2026-73419
mediumpriority · track · 0OT risk · elevatedEPSS 0.002 · 16 %ileEUUSEPSS · scored 2026-10-27
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.
cvss
Technical severity, 0–10. One row per scoring source.
base score 0–10 · higher = more severe · hover a vector to decode
weaknesses
The CWE weakness classes this flaw belongs to.
affected products (6)
Products and version ranges known to be affected.
advisories (1)
Vendor and ecosystem advisories describing this.
- GHSA-x445-f3h2-j279Auth.js: OAuth state, nonce, and PKCE check cookies are not bound to the provider that created them2026-07-23ghsa · osvUS
## 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.
also known as (3)
Other names and identifiers for this entity.
sources
Which sources assert this record, and when.
references (21)
External citations — patches, advisories, analysis.
- https://github.com/nextauthjs/next-auth/commit/5bca2399a79ba8d116ca5179b4b1ebcd152e7f05cnnvd
- https://github.com/nextauthjs/next-auth/commit/9f7a97fade9b1319bb9ac19fc9828d62e0a2a852cnnvd
- https://github.com/nextauthjs/next-auth/pull/13469cnnvd
- https://github.com/nextauthjs/next-auth/releases/tag/@auth/core@0.41.3cnnvd
- https://github.com/nextauthjs/next-auth/releases/tag/next-auth@4.24.15cnnvd
- https://github.com/nextauthjs/next-auth/releases/tag/next-auth@5.0.0-beta.32cnnvd
- https://github.com/nextauthjs/next-auth/security/advisories/GHSA-x445-f3h2-j279cnnvd
- https://github.com/nextauthjs/next-auth/commit/5bca2399a79ba8d116ca5179b4b1ebcd152e7f05enisa_euvd
Attackers weaponise vulnerabilities like this against internet-exposed services. See what is exposed on your perimeter with a free passive scan.
Free scan