GHSA-8FPG-XM3F-6CX3: Authentication Fail-Open via Unvalidated Server Responses in Auth.js

The Auth.js library (formerly next-auth) provides developers with a structured authentication wrapper for modern web applications. In next-auth version 5, the client-side wrappers interface directly with the core server-side engine via API endpoints to evaluate the authentication state of an incoming request. The vulnerability exists within this communication layer, specifically during scenarios where the core engine fails to process the request due to server-side exceptions or database connection outages.

Under normal execution, the server-side component of Auth.js processes session validation requests and returns a structured JSON payload representing the active user session. When authenticated, this payload is passed to middlewares, React Server Components (RSC), or edge handlers. However, if the session retrieval endpoint fails, it returns an HTTP 500 status code accompanied by a JSON payload describing the error.

The attack surface is exposed on any route that relies on existence-based truthiness checks of the session variable to restrict access. Because the integration layer failed to distinguish between successful session objects and server-side error descriptions, any server-side failure effectively dismantled the application's authentication boundary.

The root cause of this vulnerability lies in a combination of CWE-636 (Not Failing Closed) and CWE-252 (Unchecked Return Value). When the underlying @auth/core engine experiences a configuration mismatch, a database pool exhaustion, or an external OpenID Connect (OIDC) provider timeout, it responds to the client wrapper with an HTTP 500 status code. The body of this response contains a JSON payload detailing the exception message, such as {"message": "There was a problem with the server configuration..."}.

Prior to the patch, the next-auth integration wrappers received this HTTP response and directly resolved the promise chain by executing the .json() parsing method without evaluating the status code. The exact vulnerable instruction called getSession(_headers, _config).then((r) => r.json()) unconditionally, propagating the parsed JSON error object as the output of the session lookup function.

In JavaScript, truthiness evaluations govern common logic patterns. The only falsy values are null, undefined, false, 0, "" (empty string), and NaN. Consequently, a parsed JavaScript object representing an error evaluates to a boolean true. Because developers use existence checks like if (req.auth) or !!session to gate access, the wrapper passed this truthy error object to the authorization logic, successfully satisfying the check and failing open.

An analysis of the patch deployed in commit d008b9b764bf4b322a87e1822d1dda7789258d8f confirms the exact structure of the vulnerability. The wrapper implementation previously fetched the session and immediately parsed the response block using the .json() method:

// VULNERABLE FUNCTION
export function initAuth(config: NextAuthConfig) {
  return async (...args) => {
    // ...
    return getSession(_headers, _config).then((r) => r.json())
  }
}

The vulnerability is remediated by introducing the parseSessionResponse helper function. This helper encapsulates the response evaluation logic by checking the boolean .ok attribute of the Response object before accessing the body parser. If the response code is outside the 2xx success range (such as HTTP 500), the helper returns null to ensure the session evaluates to falsy.

// SECURE REMEDIATION PATTERN
async function parseSessionResponse(
  response: Response
): Promise<Session | null> {
  // Ensure response was successful (status 200-299)
  if (!response.ok) return null
  return (await response.json()) satisfies Session | null
}
 
export function initAuth(config: NextAuthConfig) {
  return async (...args) => {
    // ...
    // Resolves to null on error response, causing existence checks to fail closed
    return getSession(_headers, _config).then(parseSessionResponse)
  }
}

This structural change guarantees that any server-side database disruption or integration failure returns null rather than an error object. The downstream middleware and routing mechanisms can then correctly evaluate the falsy session value and restrict route access.

To exploit this vulnerability, an attacker does not require pre-existing session tokens or credentials. The exploitation relies on triggering, or waiting for, an error state in the backend engine of the web application. Common vectors to induce this state include rate-limiting the application's connection to its database pool or targeting downstream third-party identity providers to cause network timeouts.

Once the backend is in an error-producing state, any request to a protected endpoint triggers the vulnerable getSession pathway. The application server attempts to validate the session, encounters the backend error, and returns an HTTP 500 status code with the JSON error metadata. The unpatched wrapper parses this payload and sets the session value to the error object, which the authorization logic accepts as a valid session.

The official test harness validates this bypass logic by using a malformed configuration block. By defining a provider that lacks crucial endpoint URLs, the engine is forced to crash. The test verifies that prior to the patch, the resulting 500 error permitted route access, whereas the patched implementation successfully sets the session context to null:

it("sets req.auth to null in the middleware wrapper", async () => {
  const { auth } = NextAuth(brokenConfig)
  let observed: unknown = "unset"
  const handler = auth((req) => {
    observed = req.auth
  })
  const req: any = new Request("https://app.example.com/dashboard")
  await handler(req, {} as any)
  expect(observed).toBeNull()
})

The operational impact of this vulnerability is critical for applications that use existence-based authorization checks. If the application server encounters a transient database outage or API timeout, the entire authentication wall is bypassed. This bypass allows unauthenticated external attackers to read sensitive records, perform modifications on administrative routes, and access private user dashboards.

The vulnerability does not affect environments utilizing rigid session schema validation post-authentication, as those systems would fail when attempting to access non-existent user properties on the parsed error object. However, applications relying solely on boolean checks such as if (session) are completely exposed during failure intervals.

Because this vulnerability occurs during server-side errors, the duration of exposure is tied directly to the duration of the server outage. In cases where a misconfigured provider is deployed permanently, the bypass remains accessible continuously, resulting in an indefinite authorization exposure across the affected deployment.

The recommended remediation is to immediately update the next-auth dependency to version 5.0.0-beta.32 or higher. This update replaces the direct JSON parsing calls with the validated parseSessionResponse handler, preventing error objects from leaking into the authorization boundary.

If upgrading is not immediately feasible due to deployment freezes, developers should implement defensive checks in their middlewares or server components. Instead of checking truthiness via if (session), the session properties must be validated for structure. Checking for the absence of error keys or the presence of known user identifiers ensures a safe validation barrier.

// MANUAL WORKAROUND PATTERN
const session = await auth();
const isAuthenticated = session && !('message' in session) && session.user;
 
if (isAuthenticated) {
  // Allow transition
}

Additionally, verify that edge proxy configurations, web application firewalls, or load balancers do not normalize backend HTTP 500 JSON responses into HTTP 200 OK HTML error blocks. Such behavior would satisfy the client-side .ok check, potentially reintroducing the vulnerability if the response can be parsed as JSON.