Auth.js: getToken() throws an uncaught exception on malformed Bearer authorization headers
Published 23 Jul 2026 · Updated 10 Sept 2026
Affected packages
- Affected
- >=0.1.0 <0.41.3
- Fixed in
- 0.41.3
npm install @auth/core@0.41.3- Affected
- >=5.0.0-beta.0 <5.0.0-beta.32
- Fixed in
- 5.0.0-beta.32
npm install next-auth@5.0.0-beta.32- Affected
- >=4.0.6 <4.24.15
- Fixed in
- 4.24.15
npm install next-auth@4.24.15Details
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/coreexposing the samegetToken()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 owntry/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.
let token = null
try {
token = await getToken({ req, secret })
} catch {
token = null
}- Or strip/normalize the incoming
Authorizationheader at the edge (proxy, middleware) before it reachesgetToken(), rejecting values whose Bearer portion is not valid percent-encoding.
Credit
Reported by @deprrous. Thank you for the responsible disclosure.
Is GHSA-xmf8-cvqr-rfgj in any of your client repos?
Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected @auth/core, and gives you the command that fixes it.
References
- Linkgithub.com/nextauthjs/next-auth/security/advisories/GHSA-xmf8-cvqr-rfgj
- Advisorynvd.nist.gov/vuln/detail/CVE-2026-73418
- Linkgithub.com/nextauthjs/next-auth/pull/13467
- Linkgithub.com/nextauthjs/next-auth/pull/13469
- Linkgithub.com/nextauthjs/next-auth/commit/5bca2399a79ba8d116ca5179b4b1ebcd152e7f05
- Linkgithub.com/nextauthjs/next-auth/commit/e707770f00c52b3479e43422b0200b059149ed53
- Packagegithub.com/nextauthjs/next-auth
- Linkgithub.com/nextauthjs/next-auth/releases/tag/@auth/core@0.41.3
- Linkgithub.com/nextauthjs/next-auth/releases/tag/next-auth@4.24.15
- Linkgithub.com/nextauthjs/next-auth/releases/tag/next-auth@5.0.0-beta.32
Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.