CveMateVulnerability intelligence

Auth0 vulnerabilities, page 2

58 vulnerabilities

Known vulnerabilities in Auth0 products, newest first, with CVSS severity, EPSS, KEV listings and ransomware use, across 29 products.

CVE-2025-67490auth0nextjs-auth0+110mo ago10-12-2025 22:16

The Auth0 Next.js SDK is a library for implementing user authentication in Next.js applications. When using versions 4.11.0 through 4.11.2 and 4.12.0, simultaneous requests on the same client may result in improper lookups in the TokenRequestCache for the request results. This issue is fixed in versions 4.11.2 and 4.12.1.CVE-2025-67716auth0nextjs-auth0+110mo ago11-12-2025 00:21

The Auth0 Next.js SDK is a library for implementing user authentication in Next.js applications. Versions 4.9.0 through 4.12.1 contain an input-validation flaw in the returnTo parameter, which could allow attackers to inject unintended OAuth query parameters into the Auth0 authorization request. Successful exploitation may result in tokens being issued with unintended parameters. This issue is fixed in version 4.13.0.CVE-2025-46572auth0passport-wsfed-saml2+11y ago06-05-2025 20:18

passport-wsfed-saml2 provides passport strategy for both WS-fed and SAML2 protocol. A vulnerability present starting in version 3.0.5 up to and including version 4.6.3 allows an attacker to impersonate any user during SAML authentication by crafting a SAMLResponse. This can be done by using a valid SAML object that was signed by the configured IdP. Users are affected specifically when the service provider is using passport-wsfed-saml2 and a valid SAML document signed by the Identity Provider can be obtained. Version 4.6.4 contains a fix for the vulnerability.CVE-2025-46573auth0passport-wsfed-saml2+11y ago06-05-2025 20:22

passport-wsfed-saml2 provides passport strategy for both WS-fed and SAML2 protocol. A vulnerability present starting in version 3.0.5 up to and including version 4.6.3 allows an attacker to impersonate any user during SAML authentication by tampering with a valid SAML response. This can be done by adding attributes to the response. Users are affected specifically when the service provider is using `passport-wsfed-saml2` and a valid SAML Response signed by the Identity Provider can be obtained. Version 4.6.4 contains a fix for the vulnerability.CVE-2025-46344auth0nextjs-auth0+11y ago29-04-2025 20:43

The Auth0 Next.js SDK is a library for implementing user authentication in Next.js applications. Versions starting from 4.0.1 and prior to 4.5.1, do not invoke `.setExpirationTime` when generating a JWE token for the session. As a result, the JWE does not contain an internal expiration claim. While the session cookie may expire or be cleared, the JWE remains valid. This issue has been patched in version 4.5.1.CVE-2020-7948auth0login_by_auth0+16y ago01-04-2020 12:53

An issue was discovered in the Login by Auth0 plugin before 4.0.0 for WordPress. A user can perform an insecure direct object reference.CVE-2020-7947auth0login_by_auth0+16y ago01-04-2020 12:51

An issue was discovered in the Login by Auth0 plugin before 4.0.0 for WordPress. It has numerous fields that can contain data that is pulled from different sources. One issue with this is that the data isn't sanitized, and no input validation is performed, before the exporting of the user data. This can lead to (at least) CSV injection if a crafted Excel document is uploaded.CVE-2020-5391auth0wp-auth0+16y ago01-04-2020 12:50

Cross-site request forgery (CSRF) vulnerabilities exist in the Auth0 plugin before 4.0.0 for WordPress via the domain field.CVE-2020-5392auth0wp-auth0+16y ago01-04-2020 12:48

A stored cross-site scripting (XSS) vulnerability exists in the Auth0 plugin before 4.0.0 for WordPress via the settings page.CVE-2020-5263auth0auth0.js+16y ago09-04-2020 15:50

auth0.js (NPM package auth0-js) greater than version 8.0.0 and before version 9.12.3 has a vulnerability. In the case of an (authentication) error, the error object returned by the library contains the original request of the user, which may include the plaintext password the user entered. If the error object is exposed or logged without modification, the application risks password exposure. This is fixed in version 9.12.3 CVE-2020-15084auth0express-jwt+16y ago30-06-2020 16:10

In express-jwt (NPM package) up and including version 5.3.3, the algorithms entry to be specified in the configuration is not being enforced. When algorithms is not specified in the configuration, with the combination of jwks-rsa, it may lead to authorization bypass. You are affected by this vulnerability if all of the following conditions apply: - You are using express-jwt - You do not have **algorithms** configured in your express-jwt configuration. - You are using libraries such as jwks-rsa as the **secret**. You can fix this by specifying **algorithms** in the express-jwt configuration. See linked GHSA for example. This is also fixed in version 6.0.0.CVE-2020-15259auth0ad-ldap-connector+15y ago06-11-2020 19:35

ad-ldap-connector's admin panel before version 5.0.13 does not provide csrf protection, which when exploited may result in remote code execution or confidential data loss. CSRF exploits may occur if the user visits a malicious page containing CSRF payload on the same machine that has access to the ad-ldap-connector admin console via a browser. You may be affected if you use the admin console included with ad-ldap-connector versions <=5.0.12. If you do not have ad-ldap-connector admin console enabled or do not visit any other public URL while on the machine it is installed on, you are not affected. The issue is fixed in version 5.0.13.CVE-2020-15119auth0lock+16y ago19-08-2020 21:20

In auth0-lock versions before and including 11.25.1, dangerouslySetInnerHTML is used to update the DOM. When dangerouslySetInnerHTML is used, the application and its users might be exposed to cross-site scripting (XSS) attacks.CVE-2020-15240auth0omniauth-auth0+16y ago21-10-2020 17:25

omniauth-auth0 (rubygems) versions >= 2.3.0 and < 2.4.1 improperly validate the JWT token signature when using the `jwt_validator.verify` method. Improper validation of the JWT token signature can allow an attacker to bypass authentication and authorization. You are affected by this vulnerability if all of the following conditions apply: 1. You are using `omniauth-auth0`. 2. You are using `JWTValidator.verify` method directly OR you are not authenticating using the SDK’s default Authorization Code Flow. The issue is patched in version 2.4.1.CVE-2020-15125auth0auth0.js+26y ago29-07-2020 16:25

In auth0 (npm package) versions before 2.27.1, a DenyList of specific keys that should be sanitized from the request object contained in the error object is used. The key for Authorization header is not sanitized and in certain cases the Authorization header value can be logged exposing a bearer token. You are affected by this vulnerability if you are using the auth0 npm package, and you are using a Machine to Machine application authorized to use Auth0's management API CVE-2020-6753auth0login_by_auth0+16y ago01-04-2020 12:49

The Login by Auth0 plugin before 4.0.0 for WordPress allows stored XSS on multiple pages, a different issue than CVE-2020-5392.CVE-2022-29172auth0lock+14y ago05-05-2022 22:50

Auth0 is an authentication broker that supports both social and enterprise identity providers, including Active Directory, LDAP, Google Apps, and Salesforce. In versions before `11.33.0`, when the “additional signup fields” feature [is configured](https://github.com/auth0/lock#additional-sign-up-fields), a malicious actor can inject invalidated HTML code into these additional fields, which is then stored in the service `user_metdata` 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. 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. Upgrade to version `11.33.0`.CVE-2022-24794auth0express_openid_connect+24y ago31-03-2022 22:45

Express OpenID Connect is an Express JS middleware implementing sign on for Express web apps using OpenID Connect. Users of the `requiresAuth` middleware, either directly or through the default `authRequired` option, are vulnerable to an Open Redirect when the middleware is applied to a catch all route. If all routes under `example.com` are protected with the `requiresAuth` middleware, a visit to `http://example.com//google.com` will be redirected to `google.com` after login because the original url reported by the Express framework is not properly sanitized. This vulnerability affects versions prior to 2.7.2. Users are advised to upgrade. There are no known workarounds.CVE-2022-23541auth0jsonwebtoken+23y ago22-12-2022 17:52

jsonwebtoken is an implementation of JSON Web Tokens. Versions `<= 8.5.1` of `jsonwebtoken` library can be misconfigured so that passing a poorly implemented key retrieval function referring to the `secretOrPublicKey` argument from the readme link will result in incorrect verification of tokens. There is a possibility of using a different algorithm and key combination in verification, other than the one that was used to sign the tokens. Specifically, tokens signed with an asymmetric public key could be verified with a symmetric HS256 algorithm. This can lead to successful validation of forged tokens. If your application is supporting usage of both symmetric key and asymmetric key in jwt.verify() implementation with the same key retrieval function. This issue has been patched, please update to version 9.0.0.CVE-2022-23505auth0passport-wsfed-saml2+13y ago13-12-2022 07:04

Passport-wsfed-saml2 is a ws-federation protocol and SAML2 tokens authentication provider for Passport. In versions prior to 4.6.3, a remote attacker may be able to bypass WSFed authentication on a website using passport-wsfed-saml2. A successful attack requires that the attacker is in possession of an arbitrary IDP signed assertion. Depending on the IDP used, fully unauthenticated attacks (e.g without access to a valid user) might also be feasible if generation of a signed message can be triggered. This issue is patched in version 4.6.3. Use of SAML2 authentication instead of WSFed is a workaround.