High

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

  • Disclosed: 23.07.2026
  • Updated: 11.10.2026 10:22

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.

Affected software

Click a technology to see all vulnerabilities affecting it.

PlatformPackageVulnerable versionsFixed in
npm package @auth/core >= 0.1.0, < 0.41.3 0.41.3
npm package next-auth >= 5.0.0-beta.0, < 5.0.0-beta.32, >= 4.0.6, < 4.24.15 5.0.0-beta.32, 4.24.15

References

CVSS score 7.5/10
CVSS vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Weakness (CWE)
CWE-20
Platform
npm
Package
@auth/core, next-auth
Disclosed
23.07.2026
Updated
11.10.2026 10:22

Sources and licenses

OSV / GitHub Advisory Database - GHSA-xmf8-cvqr-rfgj - CC BY 4.0

Vulnerability history: next-auth

All published vulnerabilities of this package (npm package), newest first. Shows whether this is a one-off slip or a package that needs watching.

All (14) in the archive
Total entries
14
First → latest
02.2021 07.2026
Without a fix
0
Exploited in attacks
0

Severity breakdown

  • Critical 3
  • High 4
  • Medium 5
  • Low 2

Disclosures per year

  1. 2021: 1
  2. 2022: 6
  3. 2023: 2
  4. 2024: 0
  5. 2025: 1
  6. 2026: 4
Severity:
  1. Auth.js: getToken() throws an uncaught exception on malformed Bearer authorization headers this entry
    High · 7.5 CVE-2026-73418 >= 5.0.0-beta.0, < 5.0.0-beta.32, >= 4.0.6, < 4.24.15 5.0.0-beta.32, 4.24.15
  2. Critical CVE-2026-73420 >= 4.10.3, < 4.24.15, >= 5.0.0-beta.1, < 5.0.0-beta.32 4.24.15, 5.0.0-beta.32
  3. Critical · 9.1 CVE-2022-35924 >= 4.0.0, < 4.10.3, < 3.29.10 4.10.3, 3.29.10
  4. High · 7.1 CVE-2022-31127 < 3.29.8, >= 4.0.0, < 4.9.0 3.29.8, 4.9.0
  5. High · 7.5 CVE-2022-31093 < 3.29.5, >= 4.0.0, < 4.5.0 3.29.5, 4.5.0

Know which vulnerabilities affect your application

With the DockRay integration and software inventory enabled, DockRay checks reported component versions against known vulnerabilities and notifies you about confirmed matches. Coverage depends on the supported technology and available advisory data.

Connect your application
DockRay newsletter

Application security in your inbox

Important vulnerabilities, actionable guidance and practical advice for your applications. Choose your technologies and follow what matters to your project.

  • A daily digest of new vulnerabilities, critical ones included.
  • Notifications about important updates.
  • Practical advice on application security and monitoring.

Leave empty to receive updates for every technology.

Free to subscribe. Unsubscribe with one click in any email.