Auth.js - CraftedSignal Threat Feed

Auth.js (next-auth) v5 Configuration Error Leads to Authentication Bypass

hello@craftedsignal.io — Thu, 23 Jul 2026 14:59:25 +0000

Auth.js (next-auth) v5 applications are affected by a critical configuration error vulnerability, GHSA-8fpg-xm3f-6cx3, where misconfigurations can lead to a "fail-open" state, bypassing authentication. This issue, first published on July 23, 2026, impacts versions v5.0.0-beta.0 through v5.0.0-beta.31. When server-side configuration errors occur, such as missing OAuth provider settings or an unset AUTH_SECRET, the auth object, typically used to gate access, is erroneously populated with an error object instead of being null. This truthy error object causes common session existence checks (e.g., if (req.auth)) to evaluate as true for all incoming requests, including unauthenticated ones. Consequently, the application grants unauthorized access to protected resources, treating all visitors as authenticated. This silent failure mode poses a severe risk as it effectively renders authentication mechanisms useless without immediate detection.

Attack Chain

An Auth.js next-auth v5 application is deployed, utilizing existence-based session checks (e.g., if (req.auth) or !!auth) in middleware or route handlers to protect resources.
A server-side configuration error occurs within the Auth.js setup, such as an incomplete OAuth provider configuration (e.g., missing issuer or authorization endpoints for Keycloak) or an unset AUTH_SECRET environment variable.
This misconfiguration causes Auth.js to log an internal error (e.g., [auth][error] InvalidEndpoints) and populate the auth object, typically used for session data, with an error object instead of null.
When the application's middleware or route handlers perform a session check (e.g., const isLoggedIn = !!auth), the truthy error object causes isLoggedIn to evaluate as true.
All subsequent requests, including those from unauthenticated users, are treated as if they possess a valid session.
The application "fails open," granting unauthorized access to protected resources and routes that were intended for authenticated users only.
This authentication bypass occurs silently, as the application behaves as if a valid session exists for every request, potentially leading to widespread unauthorized access without explicit error indications to the user or administrators.

Impact

This vulnerability, an instance of CWE-636 (Not Failing Securely / "Failing Open") leading to improper authorization (CWE-285), can lead to severe consequences. If an affected application becomes misconfigured, all protected resources become openly accessible to anyone, regardless of authentication status. The failure is silent, meaning administrators may not be immediately aware that their authentication mechanisms are bypassed. This could result in unauthorized data exposure, manipulation, or complete compromise of systems, impacting confidentiality, integrity, and availability. While no specific victim count is provided, any organization using vulnerable next-auth versions with the described access pattern is at risk, particularly those with dynamic deployment environments where configuration changes are frequent.

Recommendation

Upgrade next-auth to the patched version (next-auth@beta or later stable release) immediately to ensure configuration errors fail closed.
Modify existing session checks in next-auth middleware and route handlers to explicitly check for a user or session property (e.g., !!req.auth?.user) instead of just !!req.auth to prevent misconfiguration from being treated as a valid session.
Implement robust deployment pipeline checks to monitor for [auth][error] log messages from your application, treating them as critical failures to prevent misconfigured applications from reaching production environments.

Auth.js getToken() Vulnerability Leads to Denial of Service

hello@craftedsignal.io — Thu, 23 Jul 2026 14:45:37 +0000

A high-severity vulnerability has been identified in the getToken() helper within the next-auth and @auth/core JavaScript libraries, specifically affecting versions <= 5.0.0-beta.25 for next-auth and < 0.41.3 for @auth/core. This flaw, tracked as CWE-20 (Improper Input Validation), enables an unauthenticated attacker to induce a denial-of-service condition. When an application that directly calls getToken() receives a request with a malformed Authorization: Bearer header containing invalid percent-encoding, the function attempts to URL-decode the value. This decoding step can trigger an uncaught exception if not explicitly handled by the application, causing the request handler to crash or become unresponsive. This impacts application availability, particularly in API routes, middleware, and server-side request handlers where getToken() is commonly employed, though it does not expose sensitive data or bypass authentication.

Attack Chain

An unauthenticated attacker crafts an HTTP request targeting a web application that uses the vulnerable getToken() helper.
The attacker includes a malformed Authorization: Bearer header in the request, where the bearer token portion contains invalid percent-encoding (e.g., %xx where xx is not a valid hexadecimal character).
The web application's API route, middleware, or server-side request handler receives the malicious request and calls the getToken() function.
The getToken() function, in the absence of a session cookie, attempts to URL-decode the malformed bearer value from the Authorization header.
Due to the invalid percent-encoding, the URL-decoding process fails and throws an uncaught exception within the getToken() helper.
Unless the application has a specific try/catch block surrounding the getToken() call, this uncaught exception propagates, leading to the crash or unresponsiveness of the request handler.
The application experiences a denial-of-service condition for that specific request, impacting availability.

Impact

The primary impact of this vulnerability is a denial of service (DoS). An unauthenticated request containing a specially crafted, malformed Authorization: Bearer header can cause an unhandled exception in any application handler that invokes the getToken() function directly. This results in the affected request failing to complete, rendering the specific endpoint unavailable for that transaction. The impact is isolated to individual requests and primarily affects application availability. It does not lead to the exposure of tokens, session data, or other sensitive information, nor does it bypass existing authentication mechanisms. The vulnerability is categorized under CWE-20: Improper Input Validation.

Recommendation

Upgrade next-auth to a patched version greater than 5.0.0-beta.31 or 4.24.14 (or @auth/core to 0.41.3 or newer) to automatically address the vulnerability.
If immediate upgrade is not possible, implement a try/catch block around all calls to getToken() within your application code to handle potential exceptions gracefully and treat them as an invalid token.
Consider deploying an edge proxy or middleware to strip or normalize incoming Authorization headers with malformed percent-encoding before they reach the application.

Auth.js Email Normalizer Vulnerability Allows Homoglyph Bypass Leading to Account Takeover

hello@craftedsignal.io — Thu, 23 Jul 2026 14:42:37 +0000

A critical vulnerability exists in Auth.js, specifically affecting next-auth versions >= 4.0.0, < 4.24.14, >= 4.10.3, < 4.24.15, >= 5.0.0-beta.1, <= 5.0.0-beta.31 and @auth/core versions >= 0.1.0, < 0.41.3, when using the default email/magic-link sign-in provider. The flaw stems from the email normalizer validating an address before applying Unicode normalization (NFKC/NFKD). This allows an attacker to craft an email address containing a Unicode character that is not an ASCII @ (U+0040) but canonicalizes to one after normalization. This bypasses the normalizer's single-@ check, causing a downstream mail library that performs Unicode normalization to interpret the address with two @ separators. Consequently, the passwordless sign-in link is misrouted to an attacker-controlled mailbox, enabling account takeover without requiring any victim interaction.

Attack Chain

An attacker identifies a target's email address and crafts a malicious version by inserting a Unicode homoglyph character that resembles '@' (e.g., victim_email[U+XXXX]attacker.com).
The attacker submits this crafted email address to the vulnerable Auth.js application's magic-link sign-in flow.
The application's default normalizeIdentifier function validates the address, incorrectly perceiving only one '@' symbol because validation occurs prior to Unicode normalization.
The application proceeds to send the magic-link email, with the crafted address passed to a downstream mail library or service.
The mail library or service, which performs Unicode normalization (e.g., NFKC) for internationalized email, processes the recipient address.
During normalization, the homoglyph character in the crafted email canonicalizes to a second '@' symbol (e.g., victim_email@attacker.com), causing the mail service to misroute the magic link.
The magic link is delivered to the attacker-controlled mailbox, enabling the attacker to authenticate and gain unauthorized access to the victim's account.

Impact

The primary impact of this vulnerability is account takeover. An attacker who knows a victim's email address can exploit this flaw to request a magic link that is subsequently delivered to an attacker-controlled mailbox. The attacker can then use this link to sign in as the victim, gaining full access to their account. No victim interaction is required for the link to be misrouted, as the attacker initiates and directly receives the authentication link. This can lead to unauthorized access to personal data, financial information, or sensitive corporate resources, depending on the scope and permissions of the compromised account.

Recommendation

Upgrade next-auth to a patched version (currently pending, refer to GHSA-7rqj-j65f-68wh for updates) immediately.
Upgrade @auth/core to a patched version (currently pending, refer to GHSA-7rqj-j65f-68wh for updates) immediately.
If immediate upgrade is not possible, implement a custom normalizeIdentifier on the email provider that calls identifier.normalize("NFKC") before any validation, and ensures only one '@' remains after normalization, as detailed in the GHSA advisory.
Alternatively, as a workaround, reject any email addresses containing non-ASCII characters if your user base does not require internationalized email addresses.