GHSA-X445-F3H2-J279

Vulnerability from github – Published: 2026-07-23 14:31 – Updated: 2026-08-13 19:05
VLAI
Summary
Auth.js: OAuth state, nonce, and PKCE check cookies are not bound to the provider that created them
Details

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.

Severity
6.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.41.2"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@auth/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.41.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.0.0-beta.31"
      },
      "package": {
        "ecosystem": "npm",
        "name": "next-auth"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0-beta.1"
            },
            {
              "fixed": "5.0.0-beta.32"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.24.14"
      },
      "package": {
        "ecosystem": "npm",
        "name": "next-auth"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.24.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-73419"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-346",
      "CWE-940"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-23T14:31:51Z",
    "nvd_published_at": "2026-08-12T21:17:41Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nAuth.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\u0027s 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\u0027s user.\n\n## Am I affected?\n\nYou may be affected if **all** of the following hold:\n\n- You use `next-auth` `\u003c= 4.24.14` or `\u003e= 5.0.0-beta.1, \u003c= 5.0.0-beta.31`, or `@auth/core` `\u003c= 0.41.2`.\n- You configure multiple OAuth/OIDC providers.\n- You allow users to link additional providers while logged in.\n- At least one configured provider\u0027s authorization request is observable by an attacker, and at least one target provider\u0027s callback can be satisfied without a PKCE verifier (i.e. it relies only on `state` or only on `nonce`).\n\nYou are **not** affected if you use a single OAuth provider, do not allow logged-in account linking, or all providers enforce PKCE.\n\n## Impact\n\n- Account-linking confusion: an attacker can get their account at a target provider linked to the victim\u0027s Auth.js user, granting the attacker persistent sign-in to the victim\u0027s account through that linked provider.\n- 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.\n\n## Patched version\n\nThe 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).\n\n## Workarounds\n\nIf you cannot upgrade immediately:\n\n- 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\u0027s verifier.\n- Avoid offering logged-in account linking across multiple providers where one provider is lower-trust or attacker-observable.\n- 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).\n\n## Credit\n\nReported by @Nadav0077. Thank you for the responsible disclosure.",
  "id": "GHSA-x445-f3h2-j279",
  "modified": "2026-08-13T19:05:32Z",
  "published": "2026-07-23T14:31:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nextauthjs/next-auth/security/advisories/GHSA-x445-f3h2-j279"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73419"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nextauthjs/next-auth/pull/13469"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nextauthjs/next-auth/commit/5bca2399a79ba8d116ca5179b4b1ebcd152e7f05"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nextauthjs/next-auth/commit/9f7a97fade9b1319bb9ac19fc9828d62e0a2a852"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nextauthjs/next-auth"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nextauthjs/next-auth/releases/tag/@auth/core@0.41.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nextauthjs/next-auth/releases/tag/next-auth@4.24.15"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nextauthjs/next-auth/releases/tag/next-auth@5.0.0-beta.32"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Auth.js: OAuth state, nonce, and PKCE check cookies are not bound to the provider that created them"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.