GHSA-8fpg-xm3f-6cx3 Auth.js: Configuration errors can cause existence-based auth checks to fail open (auth object populated with an error)

• npm next-auth: >= 5.0.0-beta.0, < 5.0.0-beta.32 → fixed in 5.0.0-beta.32

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 — 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. 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.