CVE-2026-107370 in auth0-lock
Summary
by MITRE • 10/13/2026
When a username for an Active Directory connection is a domain without a local part, the auth0-lock library initiates the authentication transaction with a GET request instead of a POST request. As a result, user-submitted form data is appended to the URL as query string parameters.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
The vulnerability described involves a critical flaw in how the Auth0 Lock JavaScript library handles username formatting for Active Directory connections within an enterprise identity management context. Specifically, when a user provides a username that consists solely of a domain name without a local part or specific account identifier, such as providing just "example.com" instead of "[email protected]", the underlying authentication logic fails to adhere to standard secure HTTP practices. Instead of initiating the authentication transaction using an HTTP POST request, which is designed to transmit data in the message body and keep it out of server logs and browser history by default, the library incorrectly defaults to an HTTP GET request. This deviation from expected behavior fundamentally alters how sensitive user credentials are transmitted across the network during the initial phase of the login process.
From a technical perspective, this misconfiguration results in all form data being appended directly to the URL as query string parameters. In web security architecture, URLs and their associated query strings are frequently logged by various intermediaries including web servers, reverse proxies, load balancers, browser history caches, and network monitoring tools. By placing sensitive authentication credentials into these logs, the vulnerability creates a persistent record of user passwords in plaintext or encoded formats that may be accessible to unauthorized parties with access to server logs or network traffic captures. This behavior contradicts established best practices for handling confidential information during web-based authentication flows, where POST requests are standard to prevent credential leakage through URL logging mechanisms.
The operational impact of this vulnerability is significant within enterprise environments relying on Active Directory integration via Auth0 Lock. Users who inadvertently enter their domain name without a specific username may have their passwords exposed in plain text logs accessible to system administrators, IT support staff, or potentially malicious actors if log access controls are insufficiently restricted. This exposure increases the risk of credential theft and subsequent unauthorized access to corporate resources. Furthermore, because query strings can be cached by browsers and intermediate proxies, there is an additional risk that sensitive authentication data could persist in shared computing environments where multiple users might have access to browser history or proxy logs.
This issue aligns with CWE-200: Information Exposure, as it leads to the unintended disclosure of sensitive information through log files and URL structures. It also relates to CWE-319: Cleartext Transmission of Sensitive Information within an Unprotected Channel, although in this specific case, if HTTPS is properly configured, the transmission itself may be encrypted in transit; however, the storage and logging aspects remain vulnerable. From a MITRE ATT&CK perspective, this behavior facilitates Credential Access techniques such as T1078: Valid Accounts or potentially aids in reconnaissance efforts by exposing authentication patterns to observers with log access. The flaw represents an implementation error where input validation for username formats does not trigger appropriate HTTP method selection logic based on the presence of a local part versus domain-only inputs.
Mitigation strategies should focus on correcting the client-side behavior within the Auth0 Lock library configuration and enforcing stricter input handling protocols. Developers integrating this library must ensure that usernames are validated to include both a local part and a domain component before initiating authentication, thereby forcing the use of POST requests as intended by secure design principles. Additionally, organizations should implement server-side logging policies that exclude query strings from access logs or mask sensitive parameters automatically. Updating to patched versions of the Auth0 Lock library where this logic error has been corrected is essential for long-term security posture improvement. Security teams should also monitor their web server and proxy logs for anomalies in authentication request methods to detect potential exploitation attempts or misconfigurations across other services using similar patterns.