Auth0 Lock EUVD-2026-100482

Exploitation requires an Active Directory (enterprise) connection configured in Auth0 Lock AND a user entering a username that is a domain with no local part (e.g. 'example.com' rather than 'user@example.com'); only this combination triggers the GET-instead-of-POST behavior that appends form data to the URL. Limiting factors: the vulnerable code path is confined to affected auth0-lock versions (14.0.0<15.0.2 and 10.9.0<13.2.1), it needs the specific AD-connection setup and the unusual username format (reflected as CVSS AC:H), and it depends on user interaction (UI:R) to submit the login form. Realized confidentiality impact further depends on an attacker gaining read access to the logs, browser history, proxy records, or Referer-leaking downstream hosts where the query string is retained.

This is a moderate-severity information-disclosure issue (CVSS 5.3, CWE-532) that should be treated as a hygiene/patch-when-convenient item rather than an emergency. The strongest mitigating signals dominate: no EPSS score is provided, the CVE is NOT on CISA KEV, and no public exploit code was identified - so exploitation status is 'no public exploit identified at time of analysis'. The CVSS vector (AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N) shows a high-complexity (AC:H) issue requiring user interaction (UI:R), which aligns with the narrow trigger condition (an AD-connection username that is a bare domain with no local part). Note a tension between the metrics and the real nature of the flaw: C:H is rated, but exploitation is passive - credentials/form data merely leak into a URL query string where they may be recorded in server logs, proxy logs, browser history, or Referer headers (classic CWE-532). There is no direct attacker-driven code path; an adversary must obtain access to those logs/artifacts afterward, which is why real-world risk is lower than the C:H component alone implies. A patch is confirmed available from the vendor, making remediation straightforward. Bottom line: real but low-urgency; prioritize behind any KEV/high-EPSS items.

A user authenticating through an Auth0 Lock widget against an Active Directory connection enters a username that is a bare domain (no local part), causing the login transaction to be sent as a GET request with the submitted form data - potentially including credentials - appended to the URL as query parameters. That URL is then recorded in web server access logs, reverse-proxy/CDN logs, browser history, and outbound Referer headers, where anyone with read access to those artifacts can later harvest the exposed data. No public proof-of-concept exploit was identified; exploitation requires the specific username format plus the high-complexity conditions reflected by CVSS AC:H/UI:R.