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.

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

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.

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.

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

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.

A vulnerability has been discovered in the Auth0 passport-wsfed-saml2 library affecting versions < 3.0.5. This vulnerability allows an attacker to impersonate another user and potentially elevate their privileges if the SAML identity provider does not sign the full SAML response (e.g., only signs the assertion within the response).

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.

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

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.

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.

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

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.

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

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.

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

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.

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.

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.

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.

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

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.

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

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.

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.

A cross-origin vulnerability has been discovered in the Auth0 auth0.js library affecting versions &lt; 8.12. This vulnerability allows an attacker to acquire authenticated users' tokens and invoke services on a user's behalf if the target site or application uses a popup callback page with auth0.popup.callback().

Auth0 Passport-SharePoint before 0.4.0 does not validate the JWT signature of an Access Token before processing. This allows attackers to forge tokens and bypass authentication and authorization mechanisms.

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.

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.