Overview The Auth0 PHP SDK contains a vulnerability due to insecure deserialization of cookie data. If exploited, since SDKs process cookie content without prior authentication, a threat actor could send a specially crafted cookie containing malicious serialized data.

Am I Affected? You are affected by this vulnerability if you meet the following preconditions:

1. Applications using the Auth0-PHP SDK, versions between 8.0.0-BETA3 to 8.3.0. 2. Applications using the following SDKs that rely on the Auth0-PHP SDK versions between 8.0.0-BETA3 to 8.3.0: a. Auth0/symfony, b. Auth0/laravel-auth0, c. Auth0/wordpress.

Fix Upgrade Auth0/Auth0-PHP to 8.3.1.

Acknowledgement Okta would like to thank Andreas Forsblom for discovering this vulnerability.

Overview Session cookies of applications using the Auth0-PHP SDK configured with CookieStore have authentication tags that can be brute forced, which may result in unauthorized access.

Am I Affected? You are affected by this vulnerability if you meet the following pre-conditions: 1. Applications using the Auth0-PHP SDK, or the following SDKs that rely on the Auth0-PHP SDK: a. Auth0/symfony, b. Auth0/laravel-auth0, c. Auth0/wordpress, 2. Session storage configured with CookieStore.

Fix Upgrade Auth0/Auth0-PHP to v8.14.0. As an additional precautionary measure, we recommend rotating your cookie encryption keys. Note that once updated, any previous session cookies will be rejected.

Acknowledgement Okta would like to thank Félix Charette for discovering this vulnerability.

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, 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. 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.

The Auth0 Next.js SDK is a library for implementing user authentication in Next.js applications. Versions before 1.6.2 do not filter out certain returnTo parameter values from the login url, which expose the application to an open redirect vulnerability. Users are advised to upgrade as soon as possible. There are no known workarounds for this issue.

Auth0 Auth0-WCF-Service-JWT before 1.0.4 leaks the expected JWT signature in an error message when it cannot successfully validate the JWT signature. If this error message is presented to an attacker, they can forge an arbitrary JWT token that will be accepted by the vulnerable application.

An issue was discovered in Auth0 auth0-aspnet and auth0-aspnet-owin. Affected packages do not use or validate the state parameter of the OAuth 2.0 and OpenID Connect protocols. This leaves applications vulnerable to CSRF attacks during authentication and authorization operations.

Auth0 angular-jwt before 0.1.10 treats whiteListedDomains entries as regular expressions, which allows remote attackers with knowledge of the jwtInterceptorProvider.whiteListedDomains setting to bypass the domain allowlist filter via a crafted domain.

For example, if the setting is initialized with:

jwtInterceptorProvider.whiteListedDomains = ['whitelisted.Example.com'];

An attacker can set up a domain whitelistedXexample.com that will pass the allow list filter, as it considers the . separator to be a regex whildcard which matches any character.

Overview

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:

javascript <script> var params = new URLSearchParams(window.location.search); var options = { auth: { redirectUrl: 'http://localhost:12345/callback', responseType: 'code', params: { scope: 'openid email', }, }, additionalSignUpFields: [{ name: 'agree', type: 'checkbox', placeholder: "I agree to Terms and Conditions for " + params.get('name'), }], }; var lock = new Auth0Lock('<CLIENTID>', '<TENANTNAME>.auth0.com', options); lock.show({ allowShowPassword: true, initialScreen: 'signUp', }); </script>

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 property is now treated as plain text to mitigate the problem. 2. A new placeholderHTML property is introduced that indicates the level of control it provides and that it should be only supplied from trusted sources.

Will this update impact my users?

This fix patches the Auth0 Lock widget and may require changes in application code, but it will not impact your users, their current state, or any existing sessions.

Developers using the placeholder property with HTML content from a trusted source should start using the placeholderHTML property to continue providing the same user experience.

Auth0 auth0.net before 6.5.4 has Incorrect Access Control because IdentityTokenValidator can be accidentally used to validate untrusted ID tokens.

Overview Versions after and including 2.3.0 are improperly validating the JWT token signature when using the JWTValidator.verify method. Improper validation of the JWT token signature when not using the default Authorization Code Flow can allow an attacker to bypass authentication and authorization.

Am I affected? You are affected by this vulnerability if all of the following conditions apply:

- You are using omniauth-auth0. - You are using JWTValidator.verify method directly OR you are not authenticating using the SDK’s default Authorization Code Flow.

How to fix that? Upgrade to version 2.4.1.

Will this update impact my users? The fix provided in this version will not affect your users.

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

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.

The Auth0 Next.js SDK is a library for implementing user authentication in Next.js applications. Versions before and including 1.4.1 are vulnerable to reflected XSS. An attacker can execute arbitrary code by providing an XSS payload in the error query parameter which is then processed by the callback handler as an error message. You are affected by this vulnerability if you are using @auth0/nextjs-auth0 version 1.4.1 or lower unless you are using custom error handling that does not return the error message in an HTML response. Upgrade to version 1.4.1 to resolve. The fix adds basic HTML escaping to the error message and it should not impact your users.

auth0-lock is Auth0's signin solution. Versions of nauth0-lock 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 or the library's languageDictionary feature is utilized and user input or data from URL parameters is incorporated into the languageDictionary. The vulnerability is patched in version 11.30.1.