next-auth

Ecosystem: npm

Downloads: 30.56 Mln

Vulnerabilities from the last (months)
  • 3CriticalAffects 5 versions
  • 4HighAffects 7 versions
  • 0MediumAffects 0 versions
  • 5ModerateAffects 9 versions
  • 2LowAffects 3 versions
Severity distribution (all time)
14vulnerabilities
  • Critical3 (21.4%)
  • High4 (28.6%)
  • Medium0 (0.0%)
  • Moderate5 (35.7%)
  • Low2 (14.3%)

Monthly breakdown

  • Critical
  • High
  • Medium
  • Moderate
  • Low
  • 4 vulnerabilities
    • Critical: 2
    • High: 1
    • Medium: 0
    • Moderate: 1
    • Low: 0
  • 1 vulnerabilities
    • Critical: 0
    • High: 0
    • Medium: 0
    • Moderate: 1
    • Low: 0
  • 1 vulnerabilities
    • Critical: 0
    • High: 0
    • Medium: 0
    • Moderate: 1
    • Low: 0
  • 1 vulnerabilities
    • Critical: 0
    • High: 1
    • Medium: 0
    • Moderate: 0
    • Low: 0
  • 2 vulnerabilities
    • Critical: 1
    • High: 0
    • Medium: 0
    • Moderate: 0
    • Low: 1
  • 1 vulnerabilities
    • Critical: 0
    • High: 1
    • Medium: 0
    • Moderate: 0
    • Low: 0
  • 1 vulnerabilities
    • Critical: 0
    • High: 1
    • Medium: 0
    • Moderate: 0
    • Low: 0
  • 1 vulnerabilities
    • Critical: 0
    • High: 0
    • Medium: 0
    • Moderate: 1
    • Low: 0
  • 1 vulnerabilities
    • Critical: 0
    • High: 0
    • Medium: 0
    • Moderate: 1
    • Low: 0
  • 1 vulnerabilities
    • Critical: 0
    • High: 0
    • Medium: 0
    • Moderate: 0
    • Low: 1

Vulnerabilities (14)

Known vulnerabilities affecting next-auth, based on data from OSV.

Vulnerabilities affecting next-auth
IDSeveritySummaryAffected versionsPublishedSource
GHSA-7rqj-j65f-68whCriticalAuth.js: Email normalizer validates the address before Unicode normalization, allowing a homoglyph @ bypass## Summary The default email-address normalizer used by the email/magic-link sign-in flow validates the address **before** applying Unicode normalization. An address can contain a Unicode character that is not an ASCII `@` (U+0040) but canonicalizes to one under NFKC/NFKD normalization (the normalization commonly applied by mail libraries and services for internationalized email). Such an address passes the normalizer's single-`@` check, but a downstream mail library that normalizes the string then sees two `@` separators and may deliver the passwordless sign-in link to a different recipient
  • >= 4.10.3, < 4.24.15
  • >= 5.0.0-beta.1, < 5.0.0-beta.32
GitHub (opens in a new tab)
GHSA-8fpg-xm3f-6cx3CriticalAuth.js: Configuration errors can cause existence-based auth checks to fail open (auth object populated with an error)### Impact `next-auth` (Auth.js) v5 applications that gate access by checking only for the **existence** of the `auth` object — the pattern shown in the official [session management / protecting resources guide](https://authjs.dev/getting-started/session-management/protecting) — are affected. When the Auth.js configuration produces a server-side error, the `auth` object exposed by the `auth()` wrapper (in middleware, Route Handlers, etc.) is **populated with an error object instead of being `null`**: ```json { "message": "There was a problem with the server configuration. Check the server l
  • >= 5.0.0-beta.0, < 5.0.0-beta.32
GitHub (opens in a new tab)
GHSA-x445-f3h2-j279ModerateAuth.js: OAuth state, nonce, and PKCE check cookies are not bound to the provider that created them## 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 pr
  • >= 5.0.0-beta.1, < 5.0.0-beta.32
  • < 4.24.15
GitHub (opens in a new tab)
GHSA-xmf8-cvqr-rfgjHighAuth.js: getToken() throws an uncaught exception on malformed Bearer authorization headers## Summary The exported `getToken()` helper (`next-auth/jwt` and `@auth/core/jwt`) can throw an uncaught exception when it reads a malformed `Authorization: Bearer …` header. When no session cookie is present, `getToken()` URL-decodes the bearer value before validating it, and malformed percent-encoding causes the decode step to throw rather than being treated as an invalid token. Because `getToken()` is commonly called in API routes, middleware, and other request handlers, a single unauthenticated request can trigger an unhandled exception in code paths that authenticate requests. ## Am I a
  • >= 5.0.0-beta.0, < 5.0.0-beta.32
  • >= 4.0.6, < 4.24.15
GitHub (opens in a new tab)
GHSA-5jpx-9hw9-2fx4ModerateNextAuthjs Email misdelivery Vulnerability### Summary NextAuth.js's email sign-in can be forced to deliver authentication emails to an attacker-controlled mailbox due to a bug in `nodemailer`'s address parser used by the project (fixed in `nodemailer` **v7.0.7**). A crafted input such as: ``` "e@attacker.com"@victim.com ``` is parsed incorrectly and results in the message being delivered to `e@attacker.com` (attacker) instead of `"<e@attacker.com>@victim.com"` (the intended recipient at `victim.com`) in violation of RFC 5321/5322 semantics. This allows an attacker to receive login/verification links or other sensitive emails intend
  • < 4.24.12
  • >= 5.0.0-beta.0, < 5.0.0-beta.30
GitHub (opens in a new tab)
GHSA-v64w-49xw-qq89ModeratePossible user mocking that bypasses basic authentication### Impact `next-auth` applications prior to version **4.24.5** that rely on the default [Middleware authorization](https://next-auth.js.org/configuration/nextjs#middleware) are affected. A bad actor could create an empty/mock user, by getting hold of a NextAuth.js-issued JWT from an interrupted OAuth sign-in flow (state, PKCE or nonce). Manually overriding the `next-auth.session-token` cookie value with this non-related JWT would let the user simulate a logged in user, albeit having no user information associated with it. (The only property on this user is an opaque randomly generated stri
  • < 4.24.5
GitHub (opens in a new tab)
GHSA-7r7x-4c4q-c4qfHighMissing proper state, nonce and PKCE checks for OAuth authentication### Impact `next-auth` applications using OAuth provider versions before `v4.20.1` are affected. A bad actor who can spy on the victim's network or able to social engineer the victim to click a manipulated login link could intercept and tamper with the authorization URL to **log in as the victim**, bypassing the CSRF protection. As an example, an attack can happen in the following scenario. > TL;DR: The attacker steals the victim's authenticated callback by intercepting and tampering with the authorization URL created by `next-auth`. 1. The victim attempts to log in to the `next-auth` sit
  • < 4.20.1
GitHub (opens in a new tab)
GHSA-p6mm-27gq-9v3pLownext-auth before v4.10.2 and v3.29.9 leaks excessive information into log### Impact An information disclosure vulnerability in `next-auth` before `v4.10.2` and `v3.29.9` allows an attacker with log access privilege to obtain excessive information such as an identity provider's secret in the log (which is thrown during OAuth error handling) and use it to leverage further attacks on the system, like impersonating the client to ask for extensive permissions. ### Patches We patched this vulnerability in `v4.10.2` and `v3.29.9` by moving the log for `provider` information to the debug level. In addition, we added a warning for having the `debug: true` option turned on
  • < 3.29.9
  • >= 4.0.0, < 4.10.2
GitHub (opens in a new tab)
GHSA-xv97-c62v-4587CriticalNextAuth.js before 4.10.3 and 3.29.10 sending verification requests (magic link) to unwanted emails### Impact `next-auth` users who are using the `EmailProvider` either in versions before `4.10.3` or `3.29.10` are affected. If an attacker could forge a request that sent a comma-separated list of emails (eg.: `attacker@attacker.com,victim@victim.com`) to the sign-in endpoint, NextAuth.js would send emails to both the attacker and the victim's e-mail addresses. The attacker could then login as a newly created user with the email being `attacker@attacker.com,victim@victim.com`. This means that basic authorization like `email.endsWith("@victim.com")` in the `signIn` callback would fail to comm
  • >= 4.0.0, < 4.10.3
  • < 3.29.10
GitHub (opens in a new tab)
GHSA-pgjx-7f9g-9463HighImproper handling of email input### Impact An attacker can pass a compromised input to the e-mail [signin endpoint](https://next-auth.js.org/getting-started/rest-api#post-apiauthsigninprovider) that contains some malicious HTML, tricking the e-mail server to send it to the user, so they can perform a phishing attack. Eg.: `balazs@email.com, <a href="http://attacker.com">Before signing in, claim your money!</a>`. This was previously sent to `balazs@email.com`, and the content of the email containing a link to the attacker's site was rendered in the HTML. This has been remedied in the following releases, by simply not renderi
  • < 3.29.8
  • >= 4.0.0, < 4.9.0
GitHub (opens in a new tab)
  • GHSA-7rqj-j65f-68whCritical
    Auth.js: Email normalizer validates the address before Unicode normalization, allowing a homoglyph @ bypass
    • >= 4.10.3, < 4.24.15
    • >= 5.0.0-beta.1, < 5.0.0-beta.32

    ## Summary The default email-address normalizer used by the email/magic-link sign-in flow validates the address **before** applying Unicode normalization. An address can contain a Unicode character that is not an ASCII `@` (U+0040) but canonicalizes to one under NFKC/NFKD normalization (the normalization commonly applied by mail libraries and services for internationalized email). Such an address passes the normalizer's single-`@` check, but a downstream mail library that normalizes the string then sees two `@` separators and may deliver the passwordless sign-in link to a different recipient

    CVE: CVE-2026-73420

  • GHSA-8fpg-xm3f-6cx3Critical
    Auth.js: Configuration errors can cause existence-based auth checks to fail open (auth object populated with an error)
    • >= 5.0.0-beta.0, < 5.0.0-beta.32

    ### Impact `next-auth` (Auth.js) v5 applications that gate access by checking only for the **existence** of the `auth` object — the pattern shown in the official [session management / protecting resources guide](https://authjs.dev/getting-started/session-management/protecting) — are affected. When the Auth.js configuration produces a server-side error, the `auth` object exposed by the `auth()` wrapper (in middleware, Route Handlers, etc.) is **populated with an error object instead of being `null`**: ```json { "message": "There was a problem with the server configuration. Check the server l

    CVE: CVE-2026-73421

  • GHSA-x445-f3h2-j279Moderate
    Auth.js: OAuth state, nonce, and PKCE check cookies are not bound to the provider that created them
    • >= 5.0.0-beta.1, < 5.0.0-beta.32
    • < 4.24.15

    ## 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 pr

    CVE: CVE-2026-73419

  • GHSA-xmf8-cvqr-rfgjHigh
    Auth.js: getToken() throws an uncaught exception on malformed Bearer authorization headers
    • >= 5.0.0-beta.0, < 5.0.0-beta.32
    • >= 4.0.6, < 4.24.15

    ## Summary The exported `getToken()` helper (`next-auth/jwt` and `@auth/core/jwt`) can throw an uncaught exception when it reads a malformed `Authorization: Bearer …` header. When no session cookie is present, `getToken()` URL-decodes the bearer value before validating it, and malformed percent-encoding causes the decode step to throw rather than being treated as an invalid token. Because `getToken()` is commonly called in API routes, middleware, and other request handlers, a single unauthenticated request can trigger an unhandled exception in code paths that authenticate requests. ## Am I a

    CVE: CVE-2026-73418

  • GHSA-5jpx-9hw9-2fx4Moderate
    NextAuthjs Email misdelivery Vulnerability
    • < 4.24.12
    • >= 5.0.0-beta.0, < 5.0.0-beta.30

    ### Summary NextAuth.js's email sign-in can be forced to deliver authentication emails to an attacker-controlled mailbox due to a bug in `nodemailer`'s address parser used by the project (fixed in `nodemailer` **v7.0.7**). A crafted input such as: ``` "e@attacker.com"@victim.com ``` is parsed incorrectly and results in the message being delivered to `e@attacker.com` (attacker) instead of `"<e@attacker.com>@victim.com"` (the intended recipient at `victim.com`) in violation of RFC 5321/5322 semantics. This allows an attacker to receive login/verification links or other sensitive emails intend

  • GHSA-v64w-49xw-qq89Moderate
    Possible user mocking that bypasses basic authentication
    • < 4.24.5

    ### Impact `next-auth` applications prior to version **4.24.5** that rely on the default [Middleware authorization](https://next-auth.js.org/configuration/nextjs#middleware) are affected. A bad actor could create an empty/mock user, by getting hold of a NextAuth.js-issued JWT from an interrupted OAuth sign-in flow (state, PKCE or nonce). Manually overriding the `next-auth.session-token` cookie value with this non-related JWT would let the user simulate a logged in user, albeit having no user information associated with it. (The only property on this user is an opaque randomly generated stri

    CVE: CVE-2023-48309

  • GHSA-7r7x-4c4q-c4qfHigh
    Missing proper state, nonce and PKCE checks for OAuth authentication
    • < 4.20.1

    ### Impact `next-auth` applications using OAuth provider versions before `v4.20.1` are affected. A bad actor who can spy on the victim's network or able to social engineer the victim to click a manipulated login link could intercept and tamper with the authorization URL to **log in as the victim**, bypassing the CSRF protection. As an example, an attack can happen in the following scenario. > TL;DR: The attacker steals the victim's authenticated callback by intercepting and tampering with the authorization URL created by `next-auth`. 1. The victim attempts to log in to the `next-auth` sit

    CVE: CVE-2023-27490

  • GHSA-p6mm-27gq-9v3pLow
    next-auth before v4.10.2 and v3.29.9 leaks excessive information into log
    • < 3.29.9
    • >= 4.0.0, < 4.10.2

    ### Impact An information disclosure vulnerability in `next-auth` before `v4.10.2` and `v3.29.9` allows an attacker with log access privilege to obtain excessive information such as an identity provider's secret in the log (which is thrown during OAuth error handling) and use it to leverage further attacks on the system, like impersonating the client to ask for extensive permissions. ### Patches We patched this vulnerability in `v4.10.2` and `v3.29.9` by moving the log for `provider` information to the debug level. In addition, we added a warning for having the `debug: true` option turned on

    CVE: CVE-2022-31186

  • GHSA-xv97-c62v-4587Critical
    NextAuth.js before 4.10.3 and 3.29.10 sending verification requests (magic link) to unwanted emails
    • >= 4.0.0, < 4.10.3
    • < 3.29.10

    ### Impact `next-auth` users who are using the `EmailProvider` either in versions before `4.10.3` or `3.29.10` are affected. If an attacker could forge a request that sent a comma-separated list of emails (eg.: `attacker@attacker.com,victim@victim.com`) to the sign-in endpoint, NextAuth.js would send emails to both the attacker and the victim's e-mail addresses. The attacker could then login as a newly created user with the email being `attacker@attacker.com,victim@victim.com`. This means that basic authorization like `email.endsWith("@victim.com")` in the `signIn` callback would fail to comm

    CVE: CVE-2022-35924

  • GHSA-pgjx-7f9g-9463High
    Improper handling of email input
    • < 3.29.8
    • >= 4.0.0, < 4.9.0

    ### Impact An attacker can pass a compromised input to the e-mail [signin endpoint](https://next-auth.js.org/getting-started/rest-api#post-apiauthsigninprovider) that contains some malicious HTML, tricking the e-mail server to send it to the user, so they can perform a phishing attack. Eg.: `balazs@email.com, <a href="http://attacker.com">Before signing in, claim your money!</a>`. This was previously sent to `balazs@email.com`, and the content of the email containing a link to the attacker's site was rendered in the HTML. This has been remedied in the following releases, by simply not renderi

    CVE: CVE-2022-31127

Showing 1-10 of 14 vulnerabilities