next-auth v5 Auth Bypass: Is Your App Failing Open? (2026)

On 2026-07-23 an Auth.js advisory landed with an unusual property: the same identifier is scored 9.1 Critical by GitHub's Advisory Database and Low by the Auth.js maintainers themselves.

Both are defensible, and the gap between them is the useful part. This is not a hole that anyone on the internet can walk through. It's a bug that converts a broken deploy into an open app, silently, in exactly the situation where you'd expect the opposite.

The three conditions

The advisory states plainly that there is no impact while the configuration is valid. That single sentence is why the severity is argued about, and it's the first thing to check.

All three, or you're not exposed. Miss any one and this advisory is not your problem.

That third row is what makes it worth writing about. A missing environment variable is not an exotic failure. It's the single most common thing that goes wrong the first time a founder deploys to Vercel, because the app ran fine locally where .env.local existed.

What actually happens

When Auth.js hits a server-side error, @auth/core returns an HTTP 500 whose body is a JSON error description. The literal payload is:

{
  "message": "There was a problem with the server configuration. Check the server logs for more information."
}

The next-auth wrapper read that response body without first checking the status code. So instead of auth being null, it became that object. And in JavaScript, an object is truthy no matter what's inside it.

// middleware.ts
export default auth((req) => {
  if (req.auth) return    // an error object is truthy, so this passes
  return NextResponse.redirect(new URL('/login', req.url))
})

The advisory's own wording is that such a check "evaluates to true for every request, including unauthenticated ones."

The two triggers it names are a Keycloak provider missing both its issuer and its authorization endpoint config, and an unset AUTH_SECRET. The release notes for the fix describe the root cause more narrowly than "any error": a non-OK session response now yields no session rather than an error object. The wrapper was parsing a failure as if it were a success.

Classified as CWE-285 (Improper Authorization) and CWE-636 (Not Failing Securely), which is the more precise name for what went wrong.

About that severity

Worth being straight about, because you'll see all three numbers cited:

No CVE was assigned, which is part of why coverage has been thin.

The CVSS 4.0 vector carries AT:P, meaning attack requirements are present. That's the formal admission that the bug needs a pre-existing misconfiguration before it does anything. A 9.1 reflects what happens when it fires: full authentication bypass. A Low reflects how often the preconditions hold. Neither is dishonest.

For a founder, the practical reading is: don't panic, do check, and treat it as one more reason that if (auth) was never a good enough guard.

Check it in five minutes

npm ls next-auth

grep -rn "if (req.auth)\|if (auth)\|!!req\.auth\b\|!!auth\b\|if (session)" \
  middleware.ts src/middleware.ts app/ src/ 2>/dev/null

curl -s -o /dev/null -w "%{http_code}\n" https://your-app.com/dashboard

The fix

Upgrade, then change the pattern. Both, not either.

npm install next-auth@5.0.0-beta.32

// before: an error object satisfies this
const isLoggedIn = !!req.auth

// after: an error object has no .user
const isLoggedIn = !!req.auth?.user

The advisory also recommends treating [auth][error] log lines as a failed health check, so a misconfigured build cannot silently reach production. That's the durable fix. The version bump closes this instance; failing the deploy on a broken auth config closes the whole class.

Three more in the same batch

Four Auth.js advisories published together. They have different affected ranges, and mixing them up is the easy mistake here.

• GHSA-7rqj-j65f-68wh (rated Critical in GitHub's DB, High by the maintainers). A Unicode homoglyph email address passes validation, then normalizes into something with multiple @ symbols, so a magic sign-in link routes to the attacker. Zero victim interaction. This one does hit v4, and @auth/core as well. Fixed in @auth/core 0.41.3, next-auth 4.24.15, and 5.0.0-beta.32.
• GHSA-xmf8-cvqr-rfgj (7.5 High, CVSS 3.1). getToken() URL-decodes the bearer value before validating it, so malformed percent-encoding throws an uncaught exception. Availability only. The advisory is explicit that it does not bypass authentication.
• GHSA-x445-f3h2-j279 (Moderate). OAuth state, nonce and PKCE cookies aren't bound to a provider.

All four are fixed by the same upgrade, which is the practical takeaway. One caution if you go read them: two of these carry version ranges in their prose that contradict their own machine-readable ranges. Trust the structured data, not the sentence.

Why this shape keeps recurring

This is the third authorization bypass in three months where the bug wasn't in the auth logic but in the thing that decides whether the auth logic runs. A Next.js middleware bypass. A Nuxt route rule that silently never matched. Now an auth object that's truthy when it should be absent.

The pattern underneath all three: a check that asks did something come back rather than did the right thing come back. Truthiness is not authentication. An error is not a session.

Which is why the durable version of this fix isn't a version number. Put the real authorization decision next to the data it protects, so that when the outer guard misbehaves, something else is still asking who you are.