CVE-2021-32641

Executive Summary

CVE-2021-32641 is a reflected cross-site scripting (XSS) vulnerability in auth0-lock, Auth0's client-side sign-in solution library, affecting all versions up to and including 11.30.0. The vulnerability is triggered when the flashMessage or languageDictionary features are used and user-controlled input (including data from URL parameters) is incorporated into these features, allowing arbitrary JavaScript execution in the context of the victim's browser. The flaw is patched in version 11.30.1. Given the library's widespread use in authentication flows for enterprise and consumer web applications, successful exploitation could lead to session hijacking, credential theft, and account takeover against users of affected applications.

Technical Analysis

auth0-lock is a JavaScript library that provides a fully embedded sign-in solution for Auth0-enabled applications. It renders login forms, handles authentication flows, and displays user-facing messages to the application's end users. The vulnerability class is reflected cross-site scripting (XSS) — the library fails to sanitize user-controlled input when rendering message content.

The attack surface exists in two distinct features:

1. flashMessage feature: This feature displays a transient message to the user after certain authentication events (e.g., "Your password has been reset"). If an application developer passes data derived from URL query parameters, form inputs, or other user-controlled sources into this feature without sanitization, the library renders that content directly into the DOM without proper output encoding, allowing the injection of HTML and JavaScript.

2. languageDictionary feature: This feature allows customization of the default UI strings displayed in the login widget (e.g., labels, error messages, titles). If attacker-controlled data is merged into the language dictionary and rendered by the library, the same injection vector is exposed.

The vulnerability is reflected, meaning the malicious payload is delivered via the URL (typically through a crafted link) and executed when the victim's browser loads the page and the library processes the flashMessage or languageDictionary data. Since the library renders content client-side, the attacker does not need to compromise the server — they only need to entice the victim to click a crafted link.

That said, whether the application reads and passes URL parameters into these features is determined by the application developer's integration code. The description states the vulnerability is exploitable when "user input or data from URL parameters is incorporated into the flashMessage or the languageDictionary" — this indicates that the typical vulnerable integration pattern involves reading query string parameters from window.location.href or URLSearchParams and directly passing them into these options without any escaping. The library itself does not perform adequate output encoding on these values.

Insufficient technical detail: The description does not specify the exact internal method names, DOM sinks, or sanitization functions involved. We do not have information on the precise code path within the library beyond the two referenced features. No function names, class names, or URLs are provided in the NVD description beyond the feature identifiers themselves. Therefore, this analysis is limited to the vulnerability-class and feature-level detail available from the NVD data.

The severity is high (CVSS 8.1) — the vector suggests a network attack over HTTP/HTTPS (AV:N), requires user interaction (UI:R) and high attack complexity (AC:H) which likely reflects the preconditions that (a) the application must use either of the two features, and (b) the application must pass URL parameters into those features. The scope is changed (S:C) because the rendered widget is often on a different origin than the application's backend APIs, meaning a successful injection could reach data outside the vulnerable widget's security context. Confidentiality and Integrity impacts are both high (C:H/I:H) — reflecting that JavaScript execution allows reading any data accessible to the page (including session tokens and API responses) and modifying page content or user-visible state. Availability is not impacted (A:N).

Exploitation Scenarios

No public PoC is available, and the attack chain below is inferred from the vulnerability class (reflected XSS) and the described features. Specific implementation details, function names, and code patterns should not be treated as fact.

Step 1: Reconnaissance and Target Identification

An attacker identifies applications using auth0-lock by inspecting page source for the library's script reference (e.g., auth0-lock.js or a CDN-hosted version), checking for a login widget with custom messages, or using fingerprinting techniques (e.g., Shodan queries for visible auth0-lock script tags). The attacker then identifies whether URL parameters are reflected into either the flashMessage or languageDictionary. This is typically determined by manual testing or by inspecting the application's JavaScript bundle.

Step 2: Triggering the Vulnerability

The relevant attack surface is present when the application reads a URL query parameter and passes it into the flashMessage or languageDictionary options. For example, if the application uses a msg query parameter to display a post-logout notification, the attacker crafts a URL where that parameter contains a malicious payload rather than benign text.

Since this is a reflected XSS, the attacker must deliver the crafted URL to the victim — typically via phishing email, messaging platform, social engineering, or by placing the link on a compromised page. The victim must click the link while authenticated to the target application.

Step 3: Payload and Execution

At the vulnerability-class level, the attacker injects an HTML/JavaScript payload into the URL parameter. A classic payload shape is <script>alert(document.cookie)</script>, but in practice an attacker would use a more stealthy payload, such as:

• Fetching an external JavaScript file and executing it.
• Using event handlers (e.g., onerror, onload) on HTML elements.
• Using javascript: URIs in attributes.
• Encoding variants to bypass naive filters (hex, base64, HTML entities).

Because the library renders the message content into the DOM without proper output encoding, the payload is interpreted as HTML and executes in the victim's browser session on the vulnerable origin. This gives the attacker full JavaScript-level control of the page context.

Step 4: Post-Exploitation Impact

With an XSS on the authentication widget, the attacker can:

• Steal authentication tokens, session cookies, or any credentials entered into the login form (via keylogging or form modification).
• Perform actions as the victim on the underlying application (if session tokens are available).
• Redirect the victim to a phishing page after stealing credentials.
• Modify the rendering of the login widget to capture credentials before they are sent to the auth server (classic credential harvesting via UI injection).
• Leverage the changed scope (S:C) to potentially reach data on other origins if any CORS headers allow it.

The authenticated victim context and the trust placed in the login widget elevate this beyond a simple nuisance XSS — successful exploitation likely results in full account takeover.

Impact Assessment

Business Impact: Auth0-lock is embedded in the customer-facing login flows of many enterprise and SaaS applications. A reflected XSS in this library directly endangers end-user accounts, which can translate to:

• Account takeover and data theft across the affected application.
• Regulatory violations (GDPR, HIPAA, PCI-DSS) if customer PII or cardholder data is exposed.
• Reputational damage due to compromise of the authentication layer.

CVSS Breakdown: The CVSS score of 8.1 (High) is driven by:

• Network vector (AV:N) — exploitability over the network.
• High attack complexity (AC:H) — requires specific (though not rare) application integration patterns.
• No privileges required (PR:N), user interaction required (UI:R) — victim must click the crafted link.
• Changed scope (S:C) — the widget's origin may differ from backend API origins, expanding the blast radius.
• High confidentiality and integrity impacts (C:H/I:H) — JavaScript execution on the vulnerable page permits reading and modifying data accessible to that page.

Blast Radius: The vulnerability affects any application using auth0-lock ≤ 11.30.0 with the vulnerable integration pattern. Because the library is used client-side, the vulnerable code runs in every end-user browser pointing at a vulnerable deployment. The EPSS percentile of 72.6% indicates moderate-to-high likelihood of exploitation in the wild.

Availability: Confirmed as not impacted (A:N) per the CVSS vector.

Detection Guidance

Sigma Rule

title: Reflected XSS in Auth0-Lock via URL Parameters
id: 8f3b9eab-2a47-4d8a-9c31-5b9c7d91e2f4
status: experimental
description: Detects reflected XSS attempts targeting auth0-lock flashMessage or languageDictionary parameters
author: Valtersit Threat Intelligence
logsource:
  category: webserver
  product: generic
detection:
  selection:
    cs-uri-query:
      - '*/lock*
      - '*flashMessage*
      - '*languageDictionary*
    cs-uri-query|contains:
      - '<script'
      - 'javascript:'
      - 'onerror'
      - 'onload'
      - '<img'
      - '<svg'
    sc-status: 200
  condition: selection
level: high
falsepositives:
  - Legitimate URL parameters containing HTML-like strings (rare)
  - Development/testing of the application
tags:
  - attack.t1190
  - attack.t1059.007
  - cve.2021.32641

YARA Rule

rule CVE_2021_32641_Auth0_Lock_Reflected_XSS
{
    meta:
        author = "Valtersit Threat Intelligence"
        description = "Detects malicious URL payloads targeting auth0-lock reflected XSS"
        cve = "CVE-2021-32641"
        date = "2024-01-01"
        score = 70
    strings:
        $flash = "flashMessage" ascii nocase
        $langdict = "languageDictionary" ascii nocase
        $lock = "auth0-lock" ascii nocase
        $script1 = "<script>" ascii nocase
        $script2 = "javascript:" ascii nocase
        $event1 = "onerror=" ascii nocase
        $event2 = "onload=" ascii nocase
        $encode1 = "%3Cscript" ascii nocase
        $encode2 = "%26%2397" ascii nocase
    condition:
        ( uint16(0) == 0x3C21 or uint16(0) == 0x3C48 ) and
        filesize < 100KB and
        ( $flash or $langdict ) and
        ( $script1 or $script2 or $event1 or $event2 or $encode1 or $encode2 )
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2021-32641 - Reflected XSS in Auth0-Lock via URL Parameters"; flow:established,to_server; content:"GET"; http_method; content:"flashMessage"; http_uri; nocase; content:"<script"; http_uri; nocase; sid:5819001; rev:1; metadata:cve CVE-2021-32641; reference:url,https://nvd.nist.gov/vuln/detail/CVE-2021-32641; classtype:web-application-attack;)

Note: This rule detects the most common payload shape (literal <script> in URI) targeting the flashMessage parameter. Analysts may add additional rules for URL-encoded variants, languageDictionary targeting, and alternate payload types (e.g., onerror, javascript:) as needed.

Elastic Detection

any where process.name == "*" and
  process.command_line like "*flashMessage*" and
  ( process.command_line like "*<script>*" or
    process.command_line like "*javascript:*" or
    process.command_line like "*onerror=*" or
    process.command_line like "*onload=*" )

Note: Since this is a client-side XSS, the most realistic detection points are at the web server access log level, not at the process level. The EQL above is presented in the requested format but should be adapted to your log source (e.g., a proxy log, IDS log, or web server access log). A more applicable EQL for a web server access log index would check url.query fields:

api-security where url.query contains "flashMessage" and
  (url.query contains "<script" or url.query contains "javascript:" or url.query contains "onerror=")

Splunk SPL Query

index=web sourcetype=access_combined
| eval req_lower=lower(uri_query)
| where req_lower like "%flashmessage%" AND (req_lower like "%<script%" OR req_lower like "%javascript:%" OR req_lower like "%onerror=%" OR req_lower like "%onload=%")
| table _time, src_ip, dest_host, uri_path, uri_query, http_user_agent
| sort - _time

For a broader net including URL-encoded payloads:

index=web
| eval dec=urldecode(uri_query)
| search dec like "*flashMessage*" AND (dec like "*<script*" OR dec like "*javascript:*")
| table _time, src_ip, dest_host, uri_query

Wazuh OSSEC Rule

<group name="web_attack,">
  <rule id="941810" level="12">
    <decoded_as>web</decoded_as>
    <match>flashMessage</match>
    <regex>(\%3C|\<)script|javascript:|onerror=|onload=</regex>
    <description>Possible reflected XSS attempt targeting CVE-2021-32641 (Auth0-Lock)</description>
    <group>web_application_attack,cve_2021_32641,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
  <rule id="941811" level="12">
    <decoded_as>web</decoded_as>
    <match>languageDictionary</match>
    <regex>(\%3C|\<)script|javascript:|onerror=|onload=</regex>
    <description>Possible reflected XSS attempt targeting CVE-2021-32641 via languageDictionary parameter</description>
    <group>web_application_attack,cve_2021_32641,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). Despite the vendor description stating the issue is fixed in version 11.30.1, no patch data appears in the tracked patch sources available in this report. It is possible the patch exists but has not been indexed, or that the vendor's fix is not being detected by the automated tracking source. Organizations should verify themselves whether version 11.30.1 or later is available in their package registry (e.g., npm) and immediately test and deploy it.

1) Immediate Mitigations (Days 0–10)

• Upgrade auth0-lock to version 11.30.1 or later if possible. This is the only definitive remediation.
• If upgrade is not immediately possible:
  • Audit all usages of flashMessage and languageDictionary in the application integration code. Ensure no URL-derived data is ever passed into these features.
  • Sanitize all user-controlled input before it reaches the library — implement HTML-encoding of any data interpolated into flashMessage or languageDictionary strings (e.g., use a library like DOMPurify to sanitize string content before passing it into the lock options).
  • Do not read URL parameters directly for message content. Re-fetch messages from server-side data or a hardcoded dictionary.
  • Deploy a WAF rule to block suspicious URL query strings containing XSS patterns targeting the flashMessage or languageDictionary keys.
  • Increase monitoring of web server logs for anomalous request patterns.

2) Patch/Upgrade Steps

• Identify the exact version of auth0-lock in use: check your application's package.json / package-lock.json (npm) or equivalent for the dependency declaration.
• Run the package manager upgrade command relevant to your stack (e.g., npm update auth0-lock, npm install auth0-lock@11.30.1).
• Re-test all authentication flows, particularly any that use the flashMessage or languageDictionary features, after upgrading.
• Verify the upgrade with an automated scan or manual test of the affected features with URL-injected payloads to confirm remediation.

3) Long-Term Hardening

• Security review of all client-side rendering: Ensure all user-influenced data rendered into DOM elements goes through a strict encoding/sanitization pipeline.
• CSP (Content Security Policy): Deploy a restrictive Content-Security-Policy header (e.g., script-src 'self') to minimize the impact of any residual XSS.
• Regular dependency updates: Implement automated dependency scanning (e.g., Dependabot, Renovate) to catch vulnerable library versions early.
• Input validation: Enforce strict input validation on all URL parameters — reject or neutralize HTML metacharacters.
• Monitoring: Establish alerts for login-flow pages being probed with XSS payloads (as per the detection rules above).
• User education: Advise end users to be cautious of unsolicited links, particularly those leading to login pages.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2021-32641 — Official NVD record with description, CVSS 8.1, and version impact information.
2. GitHub Advisory (inferred from vendor data): Auth0-lock GitHub repository advisories for version 11.30.1 — verify directly at https://github.com/auth0/lock/releases to confirm the patch release.
3. Auth0 Security Advisory Page: https://auth0.com/docs/security/bulletins — Check for the vendor-published bulletin regarding CVE-2021-32641.
4. CISA KEV: Not listed (per data available) — this CVE is not in the Known Exploited Vulnerabilities catalog as of the data reference date.
5. Exploit-DB / Packet Storm: No public PoC published at the time of this report. The absence of a public weaponized exploit increases the difficulty of exploitation but does not eliminate the risk.

Threat actor campaigns / in-the-wild evidence: No known campaign specifically leveraging this CVE was identified in the provided data. The EPSS score (0.01539, 72.6th percentile) suggests a moderate likelihood of exploitation in the wild relative to the full CVE population, though no direct ITW evidence is available in this data set.