CVE-2026-73419 in next-auth
Summary
by MITRE • 08/13/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/13/2026
The vulnerability in NextAuth.js represents a critical authentication flaw that undermines the security of applications relying on multiple identity providers. This issue affects versions prior to @auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32 where the authentication system fails to properly isolate state management between different OAuth/OIDC providers. The core problem lies in how the framework stores anti-CSRF checks, nonces, and PKCE verifiers in global cookies that lack provider-specific binding. This architectural weakness creates a cross-provider state leakage scenario that directly violates security principles established in CWE-384 and aligns with ATT&CK technique T1566 for credential access through social engineering.
The technical implementation flaw stems from the improper handling of authentication state persistence across different identity providers within the same application context. When a user initiates an authentication flow with one provider, the system generates state values including nonces and PKCE verifiers that are stored in cookies accessible to all subsequent authentication requests. This global cookie approach eliminates the necessary provider-specific validation checks that should occur during callback processing. The vulnerability becomes exploitable when applications support account linking while users are logged in, creating opportunities for attackers to manipulate the authentication flow between different providers. The lack of verification against provider identity elements such as provider ID, issuer, client ID, or redirect URI creates a persistent security gap that allows attackers to substitute authentication tokens from one provider for those of another.
The operational impact of this vulnerability extends beyond simple cross-site request forgery attacks and represents a sophisticated account takeover vector. An attacker with knowledge of an application's multi-provider setup can observe legitimate authentication flows and exploit the state leakage to link their own provider account to a victim's existing Auth.js user account. This creates persistent unauthorized access to the victim's account through the attacker's chosen provider, bypassing normal authentication controls that would otherwise prevent such access. The vulnerability specifically targets applications where account linking is permitted during active sessions, making it particularly dangerous in enterprise environments and applications with sensitive data access. The security implications align with ATT&CK technique T1531 for credential dumping and T1078 for valid accounts, as the attacker gains legitimate access to victim accounts through manipulated authentication flows rather than traditional brute force or injection attacks.
The mitigation strategy requires updating to patched versions of @auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32 where the cookie storage mechanism has been properly modified to bind state values to specific providers. This update addresses the fundamental architectural flaw by ensuring that authentication state, including nonces, PKCE verifiers, and anti-CSRF tokens, are stored in provider-specific cookies rather than global storage. The patched versions implement proper validation checks during callback processing that verify the stored state matches the identity of the provider handling the callback request. Organizations should also consider implementing additional security measures such as enhanced monitoring for unusual account linking patterns and ensuring that applications with multiple providers properly configure their authentication flows to minimize potential attack vectors. This vulnerability demonstrates the importance of maintaining secure session management practices and proper state isolation in multi-provider authentication systems, with implications extending beyond just NextAuth.js to similar frameworks that employ global cookie storage for authentication state management.