CVE-2026-73421: 
JavaScript vulnerability analysis and mitigation

CVE-2026-73421 is an authentication bypass vulnerability in NextAuth.js (Auth.js) v5 that causes existence-based authentication checks to fail open when the server encounters a configuration error. Affecting next-auth versions >= 5.0.0-beta.0 through <= 5.0.0-beta.31, the flaw allows unauthenticated users to access protected routes when the application is misconfigured. It was reported by @marc-zollingkoffer-syzygy, disclosed via GitHub Security Advisory GHSA-8fpg-xm3f-6cx3 on July 20, 2026, and assigned a CVSS v4.0 base score of 9.1 (Critical) (GitHub Advisory, Feedly).

The root cause is classified as CWE-636 (Not Failing Securely / Failing Open) and CWE-285 (Improper Authorization). When @auth/core encounters a server-side configuration error — such as a provider missing both issuer and authorization endpoint (triggering InvalidEndpoints), or an unset AUTH_SECRET — it returns an HTTP 500 response with a JSON body of { "message": "There was a problem with the server configuration..." }. The next-auth wrappers called .json() on this response without first checking the HTTP status code, so the error object was assigned to req.auth. Because this object is truthy, authorization patterns like !!auth or if (req.auth) evaluate to true for every request — including unauthenticated ones — across all auth() entry points including middleware, Route Handlers, and React Server Components. The fix introduces a parseSessionResponse() helper that returns null on any non-OK response, ensuring auth checks fail closed (GitHub Advisory, Fix Commit).

When triggered, this vulnerability silently grants every visitor — authenticated or not — access to all routes protected solely by session existence checks, effectively bypassing the application's authentication layer entirely. The confidentiality and integrity impacts are high, as attackers can access sensitive data and perform actions reserved for authenticated users. The failure mode is silent and persistent for the duration of the misconfiguration, meaning there is no visible error to administrators or users, and the exposure affects all protected routes simultaneously (GitHub Advisory).

No public proof-of-concept exploit code has been published, and there is no evidence of active in-the-wild exploitation as of the disclosure date (Feedly). The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires a precondition — the target application must be running a misconfigured instance of next-auth v5 beta — but once that condition is met, exploitation requires no authentication, no special privileges, and no user interaction, making it trivially exploitable by any network-accessible attacker.

1. Reconnaissance: Identify Next.js applications using next-auth v5 beta (versions 5.0.0-beta.0 through 5.0.0-beta.31) by inspecting HTTP response headers, JavaScript bundle contents, or package metadata exposed via public endpoints.
2. Identify misconfiguration: Probe the application's auth endpoints (e.g., /api/auth/session) for HTTP 500 responses containing { "message": "There was a problem with the server configuration..." }, which indicates a triggering misconfiguration such as a missing AUTH_SECRET or an improperly configured provider.
3. Access protected routes directly: Without providing any session cookie or authentication token, send HTTP requests directly to routes that should require authentication (e.g., /dashboard, /admin, /api/protected-resource).
4. Confirm bypass: Observe that the server responds with 200 OK and returns protected content, confirming that the !!auth check evaluated to true due to the truthy error object being assigned to req.auth.
5. Exfiltrate data or perform privileged actions: With unrestricted access to all existence-gated routes, enumerate and access sensitive data or invoke privileged API endpoints as if authenticated (GitHub Advisory, Fix Commit).

• Network: Unauthenticated HTTP requests (no session cookie or Authorization header) successfully returning 200 OK responses from routes expected to require authentication; repeated access to /api/auth/session returning HTTP 500 with body {"message":"There was a problem with the server configuration. Check the server logs for more information."}.
• Logs: Server-side log entries containing [auth][error] InvalidEndpoints: Provider "<name>" is missing both issuer and authorization endpoint config; log entries indicating AUTH_SECRET is unset or misconfigured; absence of session-related log entries for requests that successfully accessed protected resources.
• Application Behavior: Protected routes returning full content to requests with no valid session token; authentication middleware not redirecting unauthenticated users to the login page.

Upgrade next-auth to version 5.0.0-beta.32 or later, which introduces the parseSessionResponse() helper that returns null on non-OK responses, ensuring auth checks fail closed (GitHub Release). If an immediate upgrade is not possible, replace bare existence checks with property-level checks that are not satisfied by an error object — for example, use !!req.auth?.user instead of !!req.auth in middleware. Additionally, configure deployment pipelines to treat [auth][error] log lines as a failed health check so misconfigured deployments cannot silently reach production. Ensure AUTH_SECRET is set and all providers have both issuer and authorization endpoint configured (GitHub Advisory).

The vulnerability was disclosed by the NextAuth.js maintainers via a GitHub Security Advisory and credited to researcher @marc-zollingkoffer-syzygy. The advisory was noted on Infosec.exchange (Mastodon) and tracked by security aggregators including Tenable, VulDB, and OSV shortly after disclosure. Community discussion highlighted the risk of the "fail open" pattern being the officially documented approach in the Auth.js session management guide, raising concerns about how many production deployments may be silently affected during configuration drift (GitHub Advisory).