NextAuth.js CVE-2026-73418

The application must call getToken() directly from next-auth/jwt or @auth/core/jwt in an API route, middleware, or server-side request handler - applications that exclusively use the framework's auth() helper and never call getToken() themselves are NOT affected. The attacker must supply a malformed percent-encoded Bearer token in the Authorization header (e.g., 'Authorization: Bearer %ZZ'); a well-formed or absent Bearer token does not trigger the flaw. No session cookie may be present in the request; if getToken() finds a valid session cookie, the Bearer header path is bypassed entirely. The call site must not be wrapped in a try/catch block - any existing exception handling at the application level prevents the DoS from propagating. Limiting factors: requires direct API usage of getToken() (not the auth() abstraction), requires the absence of developer-applied exception handling at that call site, and requires the absence of upstream header validation or normalization. Impact is strictly per-request availability - no authentication bypass, session exposure, or persistent state corruption occurs.

The CVSS 7.5 High rating (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) accurately captures the unauthenticated, low-complexity, network-accessible nature of the attack with pure availability impact and no confidentiality or integrity risk. No EPSS score was provided in the input data, so probabilistic exploitation likelihood cannot be quantified from that signal. This CVE is not listed in the CISA KEV catalog and no public exploit code has been identified at time of analysis, meaning active widespread exploitation is not confirmed. Despite these reassuring signals, the attack is operationally trivial - any HTTP client can send a malformed Bearer header - and NextAuth.js has a broad deployment footprint across the Next.js ecosystem, meaning the realistic exposure surface is large wherever getToken() is called without exception handling. The primary limiting factor is architectural: applications that rely solely on the auth() helper rather than calling getToken() directly are not affected, which meaningfully narrows the true exposure population. No conflicting signals exist between the CVSS vector and the description; the network attack vector is consistent with the HTTP-based trigger mechanism. The per-request rather than persistent nature of the DoS constrains blast radius to individual request availability rather than service-wide outage, though under sustained traffic a vulnerable endpoint would remain continuously unavailable.

An unauthenticated attacker sends a single HTTP GET or POST request to any endpoint that calls getToken() directly, setting the Authorization header to 'Bearer %ZZ' or any other syntactically invalid percent-encoded value. The decodeURIComponent() call inside getToken() immediately throws a URIError, which propagates as an unhandled exception through the request handler, returning an error response to the attacker and denying service for that request. No exploit code is publicly available, but the attack requires no special tooling - a standard curl command with a crafted header is sufficient to trigger it.