Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
14 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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 — 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: Because this object is truthy, any authorization check of the form !!auth (or if (req.auth)) evaluates to true for every request, including unauthenticated ones. The application fails open: instead of denying access when the auth layer is broken, it grants access to everyone. A representative trigger is a provider that is missing required configuration. For example, a Keycloak provider with neither issuer nor authorization endpoint set logs: …and from that point on auth is the error object above, so !!auth is permanently true. The same fail-open behavior occurs for other…
Recommended action: Upgrade to 5.0.0-beta.32 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 affected? You are affected if all of the following hold: - You use next-auth <= 5.0.0-beta.25 (or @auth/core exposing the same getToken() implementation). - Your application calls getToken() directly — for example in a Route Handler, middleware, or server-side request handler. - You do not wrap that getToken() call in your own try/catch. You are not affected if you only use the framework's auth() helper and never…
Recommended action: Upgrade to 5.0.0-beta.32 (pre-release) or 4.24.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 than intended. This is an instance of validating before canonicalizing. Am I affected? You may be affected if all of the following hold: - You use next-auth = 4.0.0, < 4.24.14, or @auth/core = 0.1.0, < 0.41.3. - You have the email / magic-link (passwordless) provider enabled. - You rely on the built-in default identifier normalizer (you have not supplied your own normalizeIdentifier). - Your…
Recommended action: Upgrade to 5.0.0-beta.32 (pre-release) or 4.24.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 5.0.0-beta.32 (pre-release) or 4.24.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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 intended for the victim. <h2Affected NextAuthjs Version</h2 ≤ Version | Afftected -- | -- 4.24.11 | Yes 5.0.0-beta.29 | Yes POC Example Setup showing misdelivery of email <img width="1247" height="1408" alt="Screenshot from 2025-10-25 21-15-25" src="https://github.com/user-attachments/assets/456968a3-14ce-42b4-b8ca-f25b9351cf0f" / <img width="1279" height="1450" alt="Screenshot from 2025-10-25 21-14-47"…
Recommended action: Upgrade to 5.0.0-beta.30 (pre-release) or 4.24.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact next-auth applications prior to version 4.24.5 that rely on the default Middleware authorization 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 string). This vulnerability does not give access to other users' data, neither to resources that require proper authorization via scopes or other means. The created mock user has no information associated with it (ie. no name, email, accesstoken, etc.) This vulnerability can be exploited by bad actors to peek at logged in user states (e.g. dashboard layout). Note: Regardless of the vulnerability, the existence of a NextAuth.js session state can provide simple…
Recommended action: Upgrade to 4.24.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 site. For example https://next-auth-example.vercel.app/ 2. next-auth sets the checks cookies according to how the OAuth provider is configured. In this case, state and pkce are set by default for the Google Provider. <img width="1971" alt="Screen Shot 2023-03-03 at 09 54 26" src="https://user-images.githubusercontent.com/31528554/222619750-a2062bb8-99eb-4985-a75c-d75acd3da67e.png" 3. The attacker intercepts the returned…
Recommended action: Upgrade to 4.20.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 in production and documented it here. You have enabled the debug option. It is meant for development only, to help you catch issues in your authentication flow and you should consider removing this option when deploying to production. One way of only allowing debugging while not in production is to set debug: process.env.NODEENV !== "production", so you can commit this without needing to change the value. If you want…
Recommended action: Upgrade to 4.10.2 or 3.29.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 communicate a threat to the developer and would let the attacker bypass authorization, even with an @attacker.com address. Patches We patched this vulnerability in v4.10.3 and v3.29.10 by normalizing the email value that is sent to the sign-in endpoint before accessing it anywhere else. We also added a normalizeIdentifier callback on the EmailProvider configuration, where you can further tweak your requirements for what…
Recommended action: Upgrade to 4.10.3 or 3.29.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An attacker can pass a compromised input to the e-mail signin endpoint 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 rendering that e-mail in the HTML, since it should be obvious to the receiver what e-mail they used: next-auth v3 users before version 3.29.8 are impacted. (We recommend upgrading to v4, as v3 is considered unmaintained. See our migration guide) next-auth v4 users before version 4.8.0 are impacted. Patches We've released patches for this vulnerability in: - v3 - 3.29.8 - v4 - 4.9.0 You can do: (This will update to the latest v4 version, but you can change latest to 3 if you want to stay on…
Recommended action: Upgrade to 4.9.0 or 3.29.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An attacker can send a request to an app using NextAuth.js with an invalid callbackUrl query parameter, which internally we convert to a URL object. The URL instantiation would fail due to a malformed URL being passed into the constructor, causing it to throw an unhandled error which led to our API route handler timing out and logging in to fail. This has been remedied in the following releases: next-auth v3 users before version 3.29.5 are impacted. (We recommend upgrading to v4, as v3 is considered unmaintained. See our migration guide) next-auth v4 users before version 4.5.0 are impacted. Patches We've released patches for this vulnerability in: - v3 - 3.29.5 - v4 - 4.5.0 You can do: or or (This will update to the latest v4 version, but you can change latest to 3 if you want to stay on v3. This is not recommended.) Workarounds If for some reason you cannot upgrade, the workaround requires you to rely on Advanced Initialization. Here is an example: Before: After: References…
Recommended action: Upgrade to 4.5.0 or 3.29.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact We found that this vulnerability is present when the developer is implementing an OAuth 1 provider (by extension, it means Twitter, which is the only built-in provider using OAuth 1), but upgrading is still recommended. next-auth v3 users before version 3.29.3 are impacted. (We recommend upgrading to v4, as v3 is considered unmaintained. See our migration guide) next-auth v4 users before version 4.3.3 are impacted. Patches We've released patches for this vulnerability in: - v3 - 3.29.3 - v4 - 4.3.3 You can do: or or (This will update to the latest v4 version, but you can change latest to 3 if you want to stay on v3.) Workarounds If you are not able to upgrade for any reason, you can add the following configuration to your callbacks option: References This vulnerability was discovered right after https://github.com/nextauthjs/next-auth/security/advisories/GHSA-f9wg-5f46-cjmw was published and is very similar in nature. Read more about the callbacks.redirect option in the…
Recommended action: Upgrade to 4.3.3 or 3.29.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
next-auth v3 users before version 3.29.2 are impacted. (We recommend upgrading to v4 in most cases. See our migration guide).next-auth v4 users before version 4.3.2 are impacted. Upgrading to 3.29.2 or 4.3.2 will patch this vulnerability. If you are not able to upgrade for any reason, you can add a configuration to your callbacks option: If you already have a redirect callback, make sure that you match the incoming url origin against the baseUrl.
Recommended action: Upgrade to 4.3.2 or 3.29.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Implementations using the Prisma database adapter with the Email provider are impacted. Implementations using the Prisma database adapter that are not using the Email provider are not impacted. Implementations using the default database adapter (TypeORM) with the Email provider are not impacted. Implementations not using a database are not impacted. Patches This issue is fixed in 3.3.0 and newer versions. Workarounds Those not able to upgrade can alternatively disable the Email provider as a workaround. Description The Prisma database adapter was checking the verification token but not the identifier (the email address associated with the token). This made it possible to use a valid token assigned to one user, to sign in as another user when using the Prima adapter in conjunction with the Email provider. The defect is specific to the community-supported Prisma database adapter in versions <3.3.0 and is not present in the default database adapter (TypeORM). Note: The current…
Recommended action: Upgrade to 3.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.