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
Real-World Exposure
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.
@auth/corenpmnext-authnpmDescription
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @auth/core | ≥ 0.1.0&&< 0.41.3 | 0.41.3 |
| 📦npm | next-auth | ≥ 5.0.0-beta.0&&< 5.0.0-beta.32 | 5.0.0-beta.32 |
| 📦npm | next-auth | ≥ 4.0.6&&< 4.24.15 | 4.24.15 |
Detection & mitigation playbook
Open-source dependencyDetect
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.
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.
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.
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
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.