Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦
📦 npm
Not in CISA KEV
HIGH severity

CVE-2026-73418

HIGHFix: nextauthjs/next-auth#13467

CVE-2026-73418 is a high-severity (CVSS 7.5) Improper Input Validation vulnerability in @auth/core. O3 Security confirms whether CVE-2026-73418 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

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

Published
Jul 23, 2026
Updated
Aug 12, 2026
Affected
3 pkgs
Patched
3 / 3
Exploits
None indexed
Exploitation data as of Aug 12, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Real-World Exposure

3 pkgs affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

154other npm packages depend on this — each one inherits the vulnerability until it's patched upstream
@auth/corenpm
4.1Mdownloads / week
next-authnpm
5.8Mdownloads / week

Description

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.

    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 Packages

3 total 3 fixed
EcosystemPackageVulnerable rangeFix
📦npm@auth/core0.1.0&&< 0.41.30.41.3
📦npmnext-auth5.0.0-beta.0&&< 5.0.0-beta.325.0.0-beta.32
📦npmnext-auth4.0.6&&< 4.24.154.24.15

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @auth/core. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update @auth/core to 0.41.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-73418 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether CVE-2026-73418 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to CVE-2026-73418. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## 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 a
O3 Security · Impact-Aware SCA

Is CVE-2026-73418 in your dependencies?

O3 detects CVE-2026-73418 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.