CVE-2026-73421 in next-auth
Summary
by MITRE • 08/14/2026
NextAuth.js provides authentication for Next.js. From next-auth 5.0.0-beta.0 until 5.0.0-beta.32, applications that gate access by checking only for the existence of the auth object returned by the auth() wrapper can fail open when Auth.js has a server configuration error. In middleware, Route Handlers, React Server Components, and other auth() entry points, a non-OK session response is parsed into a truthy error object instead of null, so checks such as !!auth and if (req.auth) evaluate to true for unauthenticated requests. A provider missing both the issuer and authorization endpoint triggers InvalidEndpoints, and an unset AUTH_SECRET or another server configuration error can produce the same behavior. There is no impact while configuration is valid, but after a deployment becomes misconfigured, routes protected only by session existence silently grant access to every visitor. This issue is fixed in next-auth 5.0.0-beta.32.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/14/2026
The vulnerability in NextAuth.js affects versions 5.0.0-beta.0 through 5.0.0-beta.32 where applications implementing authentication checks based solely on the existence of an auth object returned by the auth() wrapper can experience a security misconfiguration leading to unauthorized access. This represents a classic fail-open scenario where the system's default behavior allows unauthenticated requests to proceed as if they were authenticated, fundamentally undermining the application's security model.
The technical flaw manifests in how NextAuth.js handles error responses from the auth() wrapper during various server-side execution contexts including middleware, route handlers, and React Server Components. When server configuration errors occur, such as missing issuer and authorization endpoints that trigger InvalidEndpoints or unset AUTH_SECRET values, the system parses non-OK session responses into truthy error objects rather than returning null values. This parsing behavior causes conditional checks like !!auth and if (req.auth) to evaluate as true even when no valid authentication has occurred, creating a security gap where unauthorized access is granted.
This vulnerability operates at the intersection of several cybersecurity principles and frameworks. From a CWE perspective, it relates to CWE-284: Improper Access Control, specifically in how the system fails to properly validate authentication state during error conditions. The behavior also aligns with ATT&CK technique T1078: Valid Accounts, as legitimate access patterns are bypassed through misconfigured server states rather than credential theft. Additionally, this represents a configuration management failure that could be categorized under CWE-16: Configuration and CWE-352: Cross-Site Request Forgery in terms of how the system fails to properly validate its own operational state.
The operational impact is significant as applications protected only by session existence checks become vulnerable to unauthorized access immediately upon deployment of misconfigured server settings. The vulnerability remains undetectable through normal operation since it only manifests after a configuration error occurs, making it particularly dangerous in production environments where configuration changes are frequent. Organizations relying on NextAuth.js for authentication may experience silent security breaches where all protected routes become accessible to any visitor without proper authentication.
The fix implemented in next-auth 5.0.0-beta.32 addresses this by ensuring that when server configuration errors occur, the auth() wrapper properly returns null or falsy values instead of truthy error objects. This change restores the expected behavior where authentication checks can reliably determine whether a user is actually authenticated rather than simply whether an error occurred during the authentication process. The mitigation strategy involves upgrading to the fixed version and implementing proper monitoring for configuration errors, as well as ensuring that applications do not rely solely on session existence checks but also validate the actual authentication state through more robust methods such as checking specific authentication properties or implementing additional security layers beyond basic session validation.