CVE-2026-107370

Executive Summary

CVE-2026-107370 is an information-disclosure weakness in the auth0-lock authentication library. When a user enters an Active Directory username that consists of a domain with no local part (for example a bare domain string rather than user@domain), the library starts the authentication transaction using an HTTP GET request instead of POST. Because GET requests carry parameters in the URL, sensitive user-submitted form data is appended to the query string, where it may be logged, cached, retained in browser history, or exposed via referrer headers. With a CVSS base score of 5.3, no known public PoC, and EPSS at 0.00281 (19.2nd percentile), near-term exploitation risk is low, but the credential-exposure class is serious for affected deployments that accept domain-only usernames.

Technical Analysis

The vulnerability is best understood at the class level because the supplied description is limited to the transaction-flow defect. auth0-lock is a client-side/front-end authentication widget used to drive login flows against Auth0 and, here, specifically against an Active Directory connection. Under normal operation, authentication submission is performed with an HTTP POST so that credentials and other form fields travel in the request body. Per the NVD description, when the supplied username is "a domain without a local part," the library instead initiates the authentication transaction with a GET request, causing the submitted form data to be appended to the URL as query string parameters.

Root cause: improper handling of an input edge case in which the username parser produces a value that the request-construction logic does not treat as a standard credential submission, resulting in fallback to a GET transaction. The security-relevant defect is CWE-532, Insertion of Sensitive Information into Log File — that is, the sensitive data that would normally be confined to a POST body is instead placed into the URL query string, which is a channel routinely recorded by web servers, proxies, reverse proxies, CDNs, WAFs, SIEM pipelines, and browser history. Any intermediary that logs request URLs therefore records the transmitted form data.

Attack surface: the login widget and the HTTP request layer of the browser. The affected component is the auth0-lock library as it interacts with an Active Directory connection. The specific affected version range is not available from tracked sources, and no file paths, function names, or parameter names beyond those in the description ("username", "Active Directory connection", "GET", "POST") are asserted here.

The CVSS vector CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N describes the constraints accurately:

• AV:N — reachable over the network.
• AC:H — the attacker does not fully control the conditions; success depends on the user supplying a domain-only username, so the vulnerable path is not guaranteed to trigger on every attempt.
• PR:N — no prior privileges required.
• UI:R — a user must interact with the login form and submit the triggering value.
• S:U — impact is scoped to the affected component.
• C:H/I:N/A:N — confidentiality only; no integrity or availability impact.
• Base score: 5.3 (Medium).

Exploitation Scenarios

No public PoC, exploit code, or Nuclei template exists for this CVE. The chain below is described at the vulnerability-class level and is inferred from the NVD description; no specific function names, endpoints, or parameters beyond those stated in the description are invented.

1. Reconnaissance / target identification. The attacker identifies an application that uses the auth0-lock library with an Active Directory connection. This is discoverable through client-side JavaScript bundles, authentication page behavior, or public fingerprinting of pages that reference the library. No authentication is needed to reach the login surface.

2. Triggering the specific flaw class. The attacker needs an in-scope user (or their own session) to submit a username that is a domain with no local part. When that value is submitted, the library initiates the authentication transaction as a GET request rather than a POST request, so the form data is appended to the URL as query string parameters. This is the core of CWE-532: sensitive data enters the URL, a channel that is broadly logged and retained.

3. Payload / execution at the vulnerability-class level. There is no code execution in this vulnerability. The "payload" is the request itself: a GET authentication request whose query string contains user-submitted form data. Because AC:H and UI:R apply, the attacker cannot force the condition remotely without the triggering input; the exploitation opportunity is the exposure of data that lands in logs and history. A practical attack chain for an actor with log access would be to harvest the query strings from web server access logs, proxy logs, WAF logs, or equivalent telemetry, and from URL retention mechanisms such as browser history, referrer metadata, and shared or cached links.

4. Post-exploitation impact. Any credential material or other sensitive values present in the form data that are captured in the query string may be recoverable from logs or retained URLs. That recovered material can be reused to authenticate to the upstream Active Directory-backed service or to pivot within the environment. Because CVSS assesses C:H but I:N and A:N, the confirmed impact is disclosure rather than modification or denial of service.

Note: no threat actor campaign or in-the-wild exploitation evidence is available. CISA KEV status is NO.

Impact Assessment

The core impact is confidentiality loss (C:H) stemming from CWE-532. Sensitive user-submitted form data that is normally confined to a POST body is instead written into GET query strings, exposing it to any system that captures URLs: web and application server access logs, reverse-proxy/CDN/WAF logs, SIEM ingestion pipelines, analytics, browser history, and referrer headers.

Business impact for affected organizations includes:

• Credential exposure: if the submitted form data contains credential material, captured URLs may yield reusable secrets, enabling account takeover against AD-backed services.
• Compliance concerns: credential material in logs conflicts with data-protection and secure-logging expectations and complicates breach-scope reporting.
• Downstream pivot: recovered valid credentials can be used for lateral movement into Active Directory-integrated systems.

Blast radius is limited by the attack conditions: the flaw only triggers when a username is a domain without a local part (AC:H) and requires user interaction (UI:R). Impact is scope-unchanged (S:U), and there is no integrity or availability impact. Overall severity is Medium (5.3), but the practical consequence for an environment that routinely logs request URLs can still be meaningful. The affected version range is unknown, so organizations cannot exclude themselves purely by version unless they validate their deployed library and login flow directly.

Detection Guidance

The rules below target the vulnerability's observable behavior: an authentication transaction initiated as a GET request carrying what should be POST-body form data, and — at the log layer — sensitive values appearing in URL query strings.

Sigma Rule

title: Auth0 Lock GET-Based Authentication Transaction with Query String Form Data
id: 6c1f9a2e-4b7d-4c3a-9e21-cve2026107370
status: experimental
description: Detects authentication transactions to an AD-backed auth0-lock flow that are issued as GET requests with user-submitted form data in the query string (CVE-2026-107370).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-107370
author: Threat Intelligence
date: 2026/01/01
logsource:
  category: webserver
  product: generic
detection:
  selection_method:
    cs-method: 'GET'
  selection_path:
    cs-uri-stem|contains:
      - '/login'
      - '/auth'
      - '/authorize'
      - '/oauth'
  selection_params:
    cs-uri-query|contains:
      - 'username='
      - 'password='
      - 'email='
  condition: selection_method and selection_path and selection_params
fields:
  - c-ip
  - cs-uri-stem
  - cs-uri-query
  - cs-method
falsepositives:
  - Legitimate GET-based OAuth redirects carrying only state/nonce parameters
  - Applications that intentionally place non-sensitive identifiers in query strings
level: medium
tags:
  - attack.credential_access
  - attack.t1552
  - cve.2026.107370

YARA Rule

rule CVE_2026_107370_Auth0_Lock_GET_Auth_Transaction
{
    meta:
        description = "Detects client-side auth0-lock code that may initiate an authentication transaction with a GET request, exposing form data in the query string (CVE-2026-107370)"
        author = "Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-107370"
        date = "2026-01-01"
        severity = "medium"

    strings:
        $lock1 = "auth0-lock" ascii nocase
        $lock2 = "Auth0Lock" ascii nocase
        $dom1  = "Active Directory" ascii nocase
        $get   = "method: " ascii
        $getv  = "GET" ascii
        $post  = "POST" ascii
        $user  = "username" ascii nocase

    condition:
        (uint32(0) == 0x04034b50 or uint32(0) == 0x504b0304 or true) and
        (any of ($lock*)) and
        $user and
        $getv and
        not $post
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-107370 Possible auth0-lock GET Authentication Transaction with Form Data in Query String"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"username="; nocase; http.uri; content:"|3D|"; pcre:"/(login|auth|authorize|oauth)/Ui"; classtype:attempted-recon; sid:2026107370; rev:1; metadata:affected_product Auth0_Lock, cve CVE_2026_107370, attack_target Web_Server, created_at 2026_01_01;)

Elastic Detection

sequence by source.ip with maxspan=5m
  [ network where http.request.method == "GET"
      and http.request.uri : ("*username=*" or "*email=*" or "*password=*")
      and http.request.uri : ("*/login*" or "*/auth*" or "*/authorize*" or "*/oauth*") ]

Alternative non-sequence form:

network where http.request.method == "GET"
  and http.request.uri : "*username=*"
  and http.request.uri : ("*/login*" or "*/auth*" or "*/authorize*")

Splunk SPL Query

index=web OR index=proxy
| eval uri=coalesce(uri, url, request_url)
| eval method=coalesce(method, http_method, cs_method)
| where method="GET" AND match(uri, "(?i)(username|email|password)=") AND match(uri, "(?i)(login|auth|authorize|oauth)")
| stats count min(_time) as first_seen max(_time) as last_seen values(uri) as urls by src_ip, dest_host
| where count > 0
| sort - count

Suggested companion search for exposed secrets already captured in logs:

index=web OR index=proxy
| where match(uri, "(?i)password=")
| rex field=uri "password=(?<exposed_password>[^&]+)"
| table _time src_ip dest_host uri exposed_password

Wazuh OSSEC Rule

<group name="web,auth0,cve_2026_107370,">
  <rule id="107370" level="10">
    <if_sid>31100</if_sid>
    <decoded_as>web-accesslog</decoded_as>
    <field name="method">GET</field>
    <url>username=</url>
    <description>CVE-2026-107370: Possible auth0-lock GET authentication transaction with form data in query string</description>
    <mitre>
      <id>T1552</id>
    </mitre>
  </rule>

  <rule id="107371" level="12">
    <if_sid>107370</if_sid>
    <description>CVE-2026-107370: Sensitive form data (password) detected in GET query string on authentication endpoint</description>
    <mitre>
      <id>T1552</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor fix, workaround, or affected-version data was available at the time of this assessment. The guidance below is defensive-in-depth and should be validated against the deployed library and login flow.

1. Immediate mitigations:

• Validate the behavior directly: test the login flow with a domain-only username and confirm whether the transaction is issued as GET or POST, and whether form data appears in the query string. This is the only reliable way to confirm exposure given the unknown version range.
• Prevent sensitive data from reaching query strings: where the widget or its configuration permits, normalize or reject domain-only usernames before submission so the standard POST path is used.
• Reduce log retention of URLs: sanitize or redact query strings in web server, reverse-proxy, CDN, and WAF access logs; disable query-string capture where it is not operationally required; restrict access to logs containing authentication URLs.
• Purge and restrict: rotate any credential that may have transited through a URL query string, and audit browser history, referrer metadata, and shared/cached links for exposed values.
• Educate users and support staff not to enter bare domains as usernames if that input leads to the GET path.

2. Patch/upgrade steps:

• Monitor Auth0 advisories and the auth0-lock project for a fixed release; no patch reference or fixed version exists as of this assessment.
• When a fix is published, upgrade auth0-lock to the fixed version, retest the domain-only-username flow, and confirm transactions are issued as POST with form data in the request body.
• If no fix becomes available, evaluate replacing the affected transaction path or enforcing the POST-only behavior at the application layer.

3. Long-term hardening:

• Enforce POST for all authentication submissions at the application and gateway level, rejecting form data in GET query strings on authentication endpoints.
• Adopt an authentication design that never places credentials or other sensitive fields in URLs; keep them strictly in request bodies.
• Implement centralized logging redaction for sensitive parameters as a standing control, and continuously monitor authentication URLs for sensitive-keyword contamination.
• Track CVE-2026-107370 and CWE-532 class issues in dependency management and secure-logging review processes.

References

• NVD — CVE-2026-107370: https://nvd.nist.gov/vuln/detail/CVE-2026-107370
• CWE-532 — Insertion of Sensitive Information into Log File: https://cwe.mitre.org/data/definitions/532.html
• Auth0 Security Advisories: https://auth0.com/security
• MITRE ATT&CK T1552 — Unsecured Credentials: https://attack.mitre.org/techniques/T1552/
• CISA Known Exploited Vulnerabilities Catalog (status: not listed): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No public PoC, exploit code, or in-the-wild exploitation evidence is available for CVE-2026-107370. CISA KEV status remains NO.