NextAuth.js: getToken() throws an uncaught exception on malformed Bearer authorization headers

CISA KEV lists vulnerabilities known to be exploited. FIRST EPSS estimates the likelihood of exploitation in the next 30 days. An unavailable score does not mean zero risk.

No exploitation or prediction data is available here for these CVEs. This does not mean they are safe or unlikely to be exploited.

NextAuth.js provides authentication for Next.js. Prior to @auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32, the exported getToken() helper in the next-auth/jwt and @auth/core/jwt modules 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 decodeURIComponent() to throw instead of treating the token as invalid. Because getToken() is commonly called in API routes, middleware, and server-side request handlers, a single unauthenticated request can trigger an unhandled exception in code paths that authenticate requests, causing a per-request denial of service without exposing tokens, sessions, or other data and without bypassing authentication. This issue is fixed in @auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32.

Source published

12 Aug 2026 20:21:11 UTC

Source modified

13 Aug 2026 12:53:44 UTC

Saved here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

Source: cve-program · CVE Program Terms of Use. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS 3.1 · 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

NextAuth.js provides authentication for Next.js. Prior to @auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32, the exported getToken() helper in the next-auth/jwt and @auth/core/jwt modules 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 decodeURIComponent() to throw instead of treating the token as invalid. Because getToken() is commonly called in API routes, middleware, and server-side request handlers, a single unauthenticated request can trigger an unhandled exception in code paths that authenticate requests, causing a per-request denial of service without exposing tokens, sessions, or other data and without bypassing authentication. This issue is fixed in @auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32.

Source published

Aug 12, 2026, 8:21:11 PM (timezone not stated)

Source modified

Aug 13, 2026, 12:53:44 PM (timezone not stated)

Saved here

14 Nov 2026 03:06:46 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

Source: euvd · ENISA EUVD · source terms and attribution apply. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

EUVD CVSS 3.1 · 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

NextAuth.js provides authentication for Next.js. Prior to @auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32, the exported getToken() helper in the next-auth/jwt and @auth/core/jwt modules 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 decodeURIComponent() to throw instead of treating the token as invalid. Because getToken() is commonly called in API routes, middleware, and server-side request handlers, a single unauthenticated request can trigger an unhandled exception in code paths that authenticate requests, causing a per-request denial of service without exposing tokens, sessions, or other data and without bypassing authentication. This issue is fixed in @auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32.

Source published

12 Aug 2026 21:17:40 UTC

Source modified

9 Sep 2026 20:58:37 UTC

Saved here

25 Oct 2026 15:19:09 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

Source: nvd · NIST NVD usage terms; underlying source attribution retained. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS 3.1 · [email protected] · Secondary · 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

## 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 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 call `getToken()` yourself, or if every `getToken()` call site already has its own exception handling. ## Impact - Denial of service: an unauthenticated request carrying a malformed Bearer authorization header can raise an unhandled exception in any handler that calls `getToken()`. - The impact is per-request and limited to availability; it does not expose tokens, sessions, or other data, and does not bypass authentication. CWE-20: Improper Input Validation. ## Patched version The fix makes `getToken()` treat a malformed Bearer value as an invalid token and return `null`, matching how other undecodable tokens are already handled. Upgrade to the first release containing this fix (to be published; this advisory will be updated with the exact patched version before publication) and no code changes are required. ## Workarounds If you cannot upgrade immediately, either: - **Config/code-level:** wrap your `getToken()` calls so a thrown error is treated as "no token", e.g. ```ts let token = null try { token = await getToken({ req, secret }) } catch { token = null } ``` - Or strip/normalize the incoming `Authorization` header at the edge (proxy, middleware) before it reaches `getToken()`, rejecting values whose Bearer portion is not valid percent-encoding. ## Credit Reported by @deprrous. Thank you for the responsible disclosure.

Source published

23 Jul 2026 14:42:55 UTC

Source modified

10 Sep 2026 03:51:12 UTC

Saved here

24 Oct 2026 13:17:17 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

Source: osv · GitHub Advisory Database · CC-BY-4.0. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Publisher rating · HIGH