GHSA-8fpg-xm3f-6cx3

### 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 // <-- always true when the configuration is broken // ... }) ``` A representative trigger is a provider that is missing required configuration. For example, a Keycloak provider with neither `issuer` nor `authorization` endpoint set logs: ``` [auth][error] InvalidEndpoints: Provider "keycloak" is missing both `issuer` and `authorization` endpoint config. At least one of them is required. ``` …and from that point on `auth` is the error object above, so `!!auth` is permanently `true`. The same fail-open behavior occurs for other server-configuration errors (for example, an unset `AUTH_SECRET`). There is **no impact while the configuration is valid**. The risk materializes when a previously-working deployment becomes misconfigured — e.g. an environment variable is changed or removed during a deploy — at which point existence-based auth checks silently stop protecting routes and all visitors are treated as authenticated. Becaus