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
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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 0.41.3 or later, 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 0.41.3 or later, 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 0.41.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.