GHSA-XMF8-CVQR-RFGJ

GHSA-XMF8-CVQR-RFGJ is a high-severity improper input validation vulnerability in @auth/core (npm), affecting versions >= 0.1.0, < 0.41.3. It is fixed in 0.41.3, 5.0.0-beta.32, 4.24.15.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

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

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.

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.

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.

The application does not adequately validate input before processing it, allowing unexpected values to reach sensitive code paths. Typical impact: varies by context: data corruption, logic bypass, or denial of service.

GHSA-XMF8-CVQR-RFGJ has a CVSS score of 7.5 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.41.3, 5.0.0-beta.32, 4.24.15); upgrading removes the vulnerable code path.

Affected versions

@auth/core (>= 0.1.0, < 0.41.3) next-auth (>= 5.0.0-beta.0, <= 5.0.0-beta.31) next-auth (>= 4.0.6, <= 4.24.14)

Security releases

@auth/core → 0.41.3 (npm) next-auth → 5.0.0-beta.32 (npm) next-auth → 4.24.15 (npm)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Upgrade the following packages to resolve this vulnerability:

@auth/core to 0.41.3 or later; next-auth to 5.0.0-beta.32 or later; next-auth to 4.24.15 or later

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is GHSA-XMF8-CVQR-RFGJ? GHSA-XMF8-CVQR-RFGJ is a high-severity improper input validation vulnerability in @auth/core (npm), affecting versions >= 0.1.0, < 0.41.3. It is fixed in 0.41.3, 5.0.0-beta.32, 4.24.15. The application does not adequately validate input before processing it, allowing unexpected values to reach sensitive code paths.
  2. How severe is GHSA-XMF8-CVQR-RFGJ? GHSA-XMF8-CVQR-RFGJ has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which packages are affected by GHSA-XMF8-CVQR-RFGJ?
    • @auth/core (npm) (versions >= 0.1.0, < 0.41.3)
    • next-auth (npm) (versions >= 5.0.0-beta.0, <= 5.0.0-beta.31)
  4. Is there a fix for GHSA-XMF8-CVQR-RFGJ? Yes. GHSA-XMF8-CVQR-RFGJ is fixed in 0.41.3, 5.0.0-beta.32, 4.24.15. Upgrade to this version or later.
  5. Is GHSA-XMF8-CVQR-RFGJ exploitable, and should I be worried? Whether GHSA-XMF8-CVQR-RFGJ is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether GHSA-XMF8-CVQR-RFGJ is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix GHSA-XMF8-CVQR-RFGJ?
    • Upgrade @auth/core to 0.41.3 or later
    • Upgrade next-auth to 5.0.0-beta.32 or later
    • Upgrade next-auth to 4.24.15 or later

Other vulnerabilities in @auth/core

CVE-IDSeverityPackage summary
GHSA-7RQJ-J65F-68WHCritical@auth/core: Auth.js: Email normalizer validates the address before Unicode normalization, allowing a homoglyph @ bypassGHSA-X445-F3H2-J279Medium@auth/core: Auth.js: OAuth state, nonce, and PKCE check cookies are not bound to the provider that created them

Stop the waste.
Protect your environment with Kodem.

Get a personalized demo
Get a personalized demo