Description Under specific preconditions, the Auth0.js SDK may improperly return user profile information using a valid access token when a specifically crafted invalid ID token is provided.

Am I Affected? Users are affected if they meet each of the following preconditions: - Applications built using Auth0.js version between 8.11.0 and 9.32.0 - The application’s access control relies on rules defined in Auth0 Actions.

Affected product and versions auth0.js SDK v8.11.0 to v9.32.0

Resolution Upgrade auth0/auth0.js to v10.0.0 or greater.

Acknowledgements Okta would like to thank Quan Le (@aleister1102) for their discovery and responsible disclosure.

Description In affected versions of the Next.js SDK, simultaneous requests that trigger a nonce retry may cause the proxy cache fetcher to perform improper lookups for the token request results.

Which Projects are Affected? Users are affected if they meet all of the following preconditions: - Applications using the auth0/nextjs-auth0 SDK, versions 4.12.0 to 4.17.0, and - Applications using the proxy handler /me/ and /my-org/ with DPoP enabled.

Affected product and versions Auth0/nextjs-auth0 v4.12.0 to 4.17.0

Resolution Upgrade Auth0/nextjs-auth0 version to v4.18.0 or greater

Acknowledgements Okta would like to thank Reynaldo Immanuel for their discovery and responsible disclosure.

Impact In applications built with the Auth0 PHP SDK, cookies are encrypted with insufficient entropy, which may result in threat actors brute-forcing the encryption key and forging session cookies.

Am I Affected? Consumers are affected if their application meets the following preconditions: - Their application is using the Auth0-PHP SDK, versions between 8.0.0 and 8.18.0 - Their application is using the Auth0-PHP SDK, or the following SDKs that rely on the Auth0-PHP SDK: - Auth0/symfony, - Auth0/laravel0-auth0, or - Auth0/wordpress

Resolution Upgrade Auth0/Auth0-PHP to version 8.19.0 or greater.

Description In applications built with the Auth0-PHP SDK, the audience validation in access tokens is performed improperly. Without proper validation, affected applications may accept ID tokens as Access tokens. Affected product and versions Projects are affected if they meet the following preconditions:

- Applications using the Auth0-PHP SDK, versions between v8.0.0 and v8.17.0, or - Applications using the following SDKs that rely on the Auth0-PHP SDK versions between v8.0.0 and v8.17.0: - a. Auth0/symfony, - b. Auth0/laravel-auth0, - c. Auth0/wordpress.

Resolution Upgrade Auth0/Auth0-PHP to version 8.18.0 or greater.

Acknowledgement Okta would like to thank Jafar Sadiq (iaf4r) for their discovery and responsible disclosure.

Description An input-validation flaw in the returnTo parameter in the Auth0 Next.js SDK 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

Am I Affected? You are affected if you meet the following preconditions: - Applications using the auth0/nextjs-auth0 SDK version prior to 4.13.0

Affected product and versions Auth0/nextjs-auth0 versions >= 4.9.0 and < 4.13.0

Resolution Upgrade Auth0/nextjs-auth0 version to v4.13.0

Acknowledgements Okta would like to thank Joshua Rogers (MegaManSec) for their discovery and responsible disclosure.

Description When using affected versions of the Next.js SDK, simultaneous requests on the same client may result in improper lookups in the TokenRequestCache for the request results.

Am I Affected? You are affected if you meet the following preconditions: - Applications using the auth0/nextjs-auth0 SDK with a singleton client instance, versions 4.11.0, 4.11.1, and 4.12.0.

Affected product and versions Auth0/nextjs-auth0 v4.11.0, v4.11.1, and v4.12.0.

Resolution Upgrade Auth0/nextjs-auth0 version to v4.11.2 or v4.12.1

Acknowledgements Okta would like to thank Joshua Rogers (MegaManSec) for their discovery and responsible disclosure.

Overview An improper signature verification vulnerability exists when using auth0/node-jws with the HS256 algorithm under specific conditions.

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

1. Application uses the auth0/node-jws implementation of JSON Web Signatures, versions <=3.2.2 || 4.0.0 2. Application uses the jws.createVerify() function for HMAC algorithms 3. Application uses user-provided data from the JSON Web Signature Protected Header or Payload in the HMAC secret lookup routines

You are NOT affected by this vulnerability if you meet any of the following preconditions: 1. Application uses the jws.verify() interface (note: auth0/node-jsonwebtoken users fall into this category and are therefore NOT affected by this vulnerability) 2. Application uses only asymmetric algorithms (e.g. RS256) 3. Application doesn’t use user-provided data from the JSON Web Signature Protected Header or Payload in the HMAC secret lookup routines

Fix Upgrade auth0/node-jws version to version 3.2.3 or 4.0.1

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

Overview In applications built with the Auth0-PHP SDK, the Bulk User Import endpoint does not validate the file path wrapper or value. Without proper validation, affected applications may accept arbitrary file paths or URLs.

Am I affected? You are affected by this vulnerability if you meet the following preconditions: 1. Applications using the Auth0-PHP SDK, versions between v3.3.0 and v8.16.0, or 2. Applications using the following SDKs that rely on the Auth0-PHP SDK versions between v3.3.0 and v8.16.0: a. Auth0/symfony, b. Auth0/laravel-auth0, c. Auth0/wordpress.

Fix Upgrade Auth0/Auth0-PHP to version 8.17.0 or greater.

Acknowledgement Okta would like to thank Mohamed Amine Saidani (pwni) for discovering this vulnerability.

Overview In Auth0 Next.js SDK versions 4.0.1 to 4.6.0, session cookies set by auth0.middleware may be cached by CDNs due to missing Cache-Control headers.

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

1. Applications using the NextJS-Auth0 SDK, versions between 4.0.1 to 4.6.0, 2. Applications using CDN or edge caching that caches responses with the Set-Cookie header. 3. If the Cache-Control header is not properly set for sensitive responses.

Fix Upgrade auth0/nextjs-auth0 to v4.6.1.

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 Account Link Extension is an extension aimed to help link accounts easily. Versions 2.3.4 to 2.6.6 do not verify the signature of the provided JWT. This allows the user the ability to supply a forged token and the potential to access user information without proper authorization. This issue has been patched in versions 2.6.7, 2.7.0, and 3.0.0. It is recommended to upgrade to version 3.0.0 or greater.

Overview

Versions <=8.5.1 of jsonwebtoken library could be misconfigured so that legacy, insecure key types are used for signature verification. For example, DSA keys could be used with the RS256 algorithm.

Am I affected?

You are affected if you are using an algorithm and a key type other than the combinations mentioned below

| Key type | algorithm | |----------|------------------------------------------| | ec | ES256, ES384, ES512 | | rsa | RS256, RS384, RS512, PS256, PS384, PS512 | | rsa-pss | PS256, PS384, PS512 |

And for Elliptic Curve algorithms:

| alg | Curve | |-------|------------| | ES256 | prime256v1 | | ES384 | secp384r1 | | ES512 | secp521r1 |

How do I fix it?

Update to version 9.0.0. This version validates for asymmetric key type and algorithm combinations. Please refer to the above mentioned algorithm / key type combinations for the valid secure configuration. After updating to version 9.0.0, If you still intend to continue with signing or verifying tokens using invalid key type/algorithm value combinations, you’ll need to set the allowInvalidAsymmetricKeyTypes option to true in the sign() and/or verify() functions.

Will the fix impact my users?

There will be no impact, if you update to version 9.0.0 and you already use a valid secure combination of key type and algorithm. Otherwise, use the allowInvalidAsymmetricKeyTypes option to true in the sign() and verify() functions to continue usage of invalid key type/algorithm combination in 9.0.0 for legacy compatibility.

Overview

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

Am I affected?

You will be affected if your application is supporting usage of both symmetric key and asymmetric key in jwt.verify() implementation with the same key retrieval function.

How do I fix it? Update to version 9.0.0.

Will the fix impact my users?

There is no impact for end users

Overview

In versions <=8.5.1 of jsonwebtoken library, lack of algorithm definition and a falsy secret or key in the jwt.verify() function can lead to signature validation bypass due to defaulting to the none algorithm for signature verification.

Am I affected? You will be affected if all the following are true in the jwt.verify() function: - a token with no signature is received - no algorithms are specified - a falsy (e.g. null, false, undefined) secret or key is passed

How do I fix it? Update to version 9.0.0 which removes the default support for the none algorithm in the jwt.verify() method.

Will the fix impact my users?

There will be no impact, if you update to version 9.0.0 and you don’t need to allow for the none algorithm. If you need 'none' algorithm, you have to explicitly specify that in jwt.verify() options.

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.

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.

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.

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.

Express OpenID Connect is express JS middleware implementing sign on for Express web apps using OpenID Connect. Versions before and including 2.5.1 do not regenerate the session id and session cookie when user logs in. This behavior opens up the application to various session fixation vulnerabilities. Versions 2.5.2 contains a patch for this issue.

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.

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.

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

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

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

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.

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.