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.

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.

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.

The Login by Auth0 plugin before 4.0.0 for WordPress allows stored XSS on multiple pages, a different issue than CVE-2020-5392.

Cross-site request forgery (CSRF) vulnerabilities exist in the Auth0 plugin before 4.0.0 for WordPress via the domain field.

A stored cross-site scripting (XSS) vulnerability exists in the Auth0 plugin before 4.0.0 for WordPress via the settings page.

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

The Auth0 Auth0.js library before 9.3 has CSRF because it mishandles the case where the authorization response lacks the state parameter.

The Auth0 authentication service before 2017-10-15 allows privilege escalation because the JWT audience is not validated.

CSRF exists in the Auth0 authentication service through 14591 if the Legacy Lock API flag is enabled.

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

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

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.

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.

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.

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.

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

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.

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.

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.

In jsonwebtoken node module before 4.2.2 it is possible for an attacker to bypass verification when a token digitally signed with an asymmetric key (RS/ES family) of algorithms but instead the attacker send a token digitally signed with a symmetric algorithm (HS family).