Skip to content

← Public intelligence

npm package

auth0-lock

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. Medium, CVSS 6.1npmAmendedPublished

    Cross-site Scripting in Auth0 Lock

    CVE-2022-29172 · GHSA-7ww6-75fj-jcj7

    Affected
    • npm auth0-lock < 11.33.0
    Fixed in
    11.33.0· Vendor fix available
    Issue
    In versions before and including 11.32.2, when the “additional signup fields” feature is configured, a malicious actor can inject invalidated HTML code into these additional fields, which is then stored in the service usermetdata payload (using the name property). Verification emails, when applicable, are generated using this metadata. It is therefor possible for an actor to craft a malicious link by injecting HTML, which is then rendered as the recipient's name within the delivered email template. Am I affected? You are impacted by this vulnerability if you are using auth0-lock version 11.32.2 or lower and are using the “additional signup fields” feature in your application. How to fix that? Upgrade to version 11.33.0. Will this update impact my users? Additional signup fields that have been added to the signup tab on Lock will have HTML tags stripped from user input from version 11.33.0 onwards. The user will not receive any validation warning or feedback, but backend data…

    Recommended action: Upgrade to 11.33.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  2. High, CVSS 8.1npmAmendedPublished

    Reflected XSS when using flashMessages or languageDictionary

    CVE-2021-32641 · GHSA-jr3j-whm4-9wwm

    Affected
    • npm auth0-lock < 11.30.1
    Fixed in
    11.30.1· Vendor fix available
    Issue
    Versions before and including 11.30.0 are vulnerable to reflected XSS. An attacker can execute arbitrary code when the library's - flashMessage feature is utilized and user input or data from URL parameters is incorporated into the flashMessage. - languageDictionary feature is utilized and user input or data from URL parameters is incorporated into the languageDictionary. Am I affected? You are affected by this vulnerability if you are using auth0-lock version 11.30.0 or lower and all of the following conditions apply: - You are utilizing flashMessage feature. - User input or data from URL parameters is incorporated into the flashMessage. An example of a vulnerable snippet where query parameters are used to populate the text property of a flashMessage. OR - You are utilizing languageDictionary feature. - User input or data from URL parameters is used in languageDictionary properties. An example of a vulnerable snippet where query parameters are used to populate the…

    Recommended action: Upgrade to 11.30.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  3. Medium, CVSS 6.4npmAmendedPublished

    DOM-based XSS in auth0-lock

    CVE-2020-15119 · GHSA-6gg3-pmm7-97xc

    Affected
    • npm auth0-lock <= 11.25.1
    Fixed in
    11.26.3· Vendor fix available
    Issue
    Versions before and including 11.25.1 are using dangerouslySetInnerHTML to display an informational message when used with a Passwordless or Enterprise connection. - For Passwordless connection, the value of the input (email or phone number) is displayed back to the user while waiting for verification code input. - For Enterprise connection, the value of the input (IdP Domain) from the Enterprise connection setup screen (Auth0 Dashboard) is displayed back to the user when the lock widget opens. When Passwordless or Enterprise connection is used, the application and its users might be exposed to cross-site scripting (XSS) attacks. Am I affected? You are affected by this vulnerability if all of the following conditions apply: - You are using auth0-lock - You are using Passwordless or Enterprise connection mode How to fix that? Upgrade to version 11.26.3 Will this update impact my users? The fix provided in patch will not affect your users. Credit https://github.com/mvisat

    Recommended action: Upgrade to 11.26.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  4. Medium, CVSS 6.1npmAmendedPublished

    auth0-lock vulnerable to XSS via unsanitized placeholder property

    CVE-2019-20174 · GHSA-w2pf-g6r8-pg22

    Affected
    • npm auth0-lock < 11.21.0
    Fixed in
    11.21.0· Vendor fix available
    Issue
    Auth0 Lock version 11.20.4 and earlier did not properly sanitize the generated HTML code. Customers using the additionalSignUpFields customization option to add a checkbox to the sign-up dialog that are passing a placeholder property obtained from an untrusted source (e.g. a query parameter) could allow cross-site scripting (XSS) on their signup pages. Am I affected? You are affected by this vulnerability if all of the following conditions apply: - You are using Auth0 Lock version 11.20.4 or earlier. - You pass additionalSignUpFields as options when initializing Lock which includes a field of type checkbox whose placeholder value is obtained from an untrusted source. An example of a vulnerable snippet is the following where the placeholder value is partially user-controlled by the name query parameter: How to fix that? Developers using Auth0’s signin solution Lock need to upgrade to version 11.21.0 or later. Version 11.21.0 introduces two changes: 1. The existing placeholder…

    Recommended action: Upgrade to 11.21.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →