GHSA-8fpg-xm3f-6cx3

Auth.js: Configuration errors can cause existence-based auth checks to fail open (auth object populated with an error)

Published

2026-07-23

Modified

2026-07-23

Sources

github-advisory

Summary

### Impact `next-auth` (Auth.js) v5 applications that gate access by checking only for the **existence** of the `auth` object — the pattern shown in the official [session management / protecting resources guide](https://authjs.dev/getting-started/session-management/protecting) — are affected. When the Auth.js configuration produces a server-side error, the `auth` object exposed by the `auth()` wrapper (in middleware, Route Handlers, etc.) is **populated with an error object instead of being `null`**: ```json { "message": "There was a problem with the server configuration. Check the server logs for more information." } ``` Because this object is truthy, any authorization check of the form `!!auth` (or `if (req.auth)`) evaluates to `true` for **every** request, including unauthenticated ones. The application *fails open*: instead of denying access when the auth layer is broken, it grants access to everyone. ```ts // middleware.ts — affected pattern export default auth((req) => { const { nextUrl, auth } = req const isLoggedIn = !!auth // `. To upgrade: ```sh npm i next-auth@beta ``` ```sh yarn add next-auth@beta ``` ```sh pnpm add next-auth@beta ``` ### Workarounds If you cannot upgrade immediately, check for a concrete user/session property rather than the bare object, so a configuration-error object is not treated as an authenticated session: ```ts // middleware.ts export default auth((req) => { // `auth.user` is only present on a real session; resilient to config-error objects const isLoggedIn = !!req.auth?.user // ... }) ``` As defense in depth, make Auth.js configuration errors fail loudly in your deployment pipeline (for example, treat `[auth][error]` log lines as a failed health check) so a broken configuration cannot silently reach production. As always, an existing session indicates authentication only — for authorization, perform an explicit role/permission check rather than relying on session existence. See the [role-based access control guide](https://authjs.dev/guides/role-based-access-control). ### References - Protecting resources / session management: https://authjs.dev/getting-started/session-management/protecting - Role-based access control (RBAC): https://authjs.dev/guides/role-based-access-control - Auth.js error reference: https://authjs.dev/reference/core/errors ### For more information If you have any concerns, Auth.js requests responsible disclosure, outlined here: https://authjs.dev/security ### Credits Reported by @marc-zollingkoffer-syzygy.

Affected packages

Remediation: Upgrade to 5.0.0-beta.32 or later.

References

• https://github.com/advisories/GHSA-8fpg-xm3f-6cx3