CVE-2026-73419: NextAuth.js Auth Bypass Vulnerability

CVE-2026-73419 Overview

CVE-2026-73419 affects NextAuth.js (Auth.js), an authentication library for Next.js applications. The flaw stems from OAuth/OIDC anti-CSRF state, nonce, and PKCE verifier values stored in global cookies that are not bound to the provider that created them. On callback, a check value minted for one provider satisfies the callback for a different provider because the stored cookie is never validated against the callback provider's identity, issuer, client ID, or redirect URI.

In multi-provider applications that allow account linking while a user is signed in, an attacker can lure a victim into starting a legitimate same-origin flow and link the attacker's provider account to the victim's Auth.js user. The linked account then grants the attacker persistent access.

Critical Impact
Successful exploitation enables persistent account takeover through unauthorized OAuth account linking, granting the attacker durable sign-in access to the victim's Auth.js identity.

Affected Products

@auth/core prior to 0.41.3
next-auth prior to 4.24.15
next-auth 5.0.0-beta prior to 5.0.0-beta.32

Discovery Timeline

2026-08-12 - CVE-2026-73419 published to the National Vulnerability Database (NVD)
2026-08-12 - Last updated in NVD database

Technical Details for CVE-2026-73419

Vulnerability Analysis

Auth.js implements OAuth 2.0 and OpenID Connect (OIDC) checks such as state, nonce, and PKCE code_verifier to defend against cross-site request forgery and code-interception attacks. These values are minted at the start of an authorization request and validated on the provider callback. In vulnerable releases, the check values are sealed into cookies with generic names shared across providers, and the sealed payload does not record which provider issued them.

When the callback handler runs, it decodes the cookie and validates the check value against the incoming authorization response. It does not compare the cookie's originating provider ID against the provider being called back. An authorization flow started with Provider A can therefore satisfy a callback for Provider B, breaking the trust boundary between distinct identity providers.

This weakness is categorized as CWE-345: Insufficient Verification of Data Authenticity. Exploitation requires a multi-provider deployment that permits account linking while the user is signed in and a target provider whose callback can succeed without a PKCE verifier.

Root Cause

The root cause is that the sealed cookie payload for OAuth checks stored only the check value and omitted the provider identifier. Any callback handler that could decode the cookie accepted it as valid regardless of which provider had produced it.

Attack Vector

The attacker starts an authorization request with their target provider and captures the response parameters. The attacker then lures an authenticated victim to initiate a same-origin sign-in flow with a different provider. The victim's browser overwrites or reuses the shared check cookie. The attacker completes the callback for the target provider using the previously captured response, causing Auth.js to link the attacker-controlled provider account to the victim's session.

typescript

// Patch: bind sealed OAuth check payload to the originating provider
// packages/next-auth/src/core/lib/oauth/checks.ts
     value: await jwt.encode({
       ...options.jwt,
       maxAge,
-      token: { value },
+      token: { value, provider: options.provider.id },
       salt: name,
     }),
     options: { ...cookies[type].options, expires },

Source: GitHub commit 5bca2399

typescript

// Patch: add optional provider field to sealed CookiePayload
// packages/core/src/lib/actions/callback/oauth/checks.ts
 interface CookiePayload {
   value: string
+  /**
+   * The id of the provider that created this cookie. Since the cookie names
+   * are not provider-specific, the id is stored in the sealed payload and
+   * checked on callback.
+   */
+  provider?: string
 }

 const COOKIE_TTL = 60 * 15 // 15 minutes

Source: GitHub commit 9f7a97fa

Detection Methods for CVE-2026-73419

Indicators of Compromise

Auth.js accounts table entries where a new provider was linked to an existing user without a corresponding sign-in log for that user
Callback requests where the referring authorization request URL indicates a different provider than the callback endpoint
Sudden appearance of unfamiliar OAuth provider identities linked to privileged accounts

Detection Strategies

Audit the Auth.js accounts persistence layer for links created shortly after a session started an unrelated provider sign-in flow
Inspect application logs for state or nonce cookies whose sealed payload lacks a provider field after upgrade, which indicates residual pre-patch cookies
Correlate /api/auth/signin/<provider> requests with /api/auth/callback/<other-provider> completions from the same session

Monitoring Recommendations

Alert on OAuth account linking events for administrative or high-value users and require step-up verification
Log the provider ID recorded in the sealed check cookie and compare it to the callback provider on every request
Monitor for repeated callback attempts using stale or replayed authorization codes

How to Mitigate CVE-2026-73419

Immediate Actions Required

Upgrade to @auth/core 0.41.3, next-auth 4.24.15, or next-auth 5.0.0-beta.32 as soon as possible
Review recently linked OAuth accounts and unlink any that cannot be attributed to legitimate user action
Force session invalidation for users whose accounts show unexpected provider links

Patch Information

The maintainers fixed the flaw by storing the originating provider ID inside the sealed check cookie and verifying it during callback processing. Fixed releases are available at @auth/core 0.41.3, next-auth 4.24.15, and next-auth 5.0.0-beta.32. Full details are in GHSA-x445-f3h2-j279 and pull request #13469.

Workarounds

Disable account linking while a user is signed in until the patched version is deployed
Reduce the multi-provider surface by temporarily removing providers that do not enforce PKCE
Require re-authentication with the currently linked primary provider before permitting any new provider link

bash

# Upgrade to patched releases
npm install next-auth@4.24.15
# or, for Auth.js v5 beta users
npm install next-auth@5.0.0-beta.32
# or, for @auth/core consumers
npm install @auth/core@0.41.3