Aeneasr

**Name of the Vulnerable Software and Affected Versions** Ory Kratos versions prior to 1.3.0 **Description** Ory Kratos is an identity, user management, and authentication system for cloud services. The `highest available` setting incorrectly assumes the identity's highest available Authenticator Assurance Level (AAL) is `aal1` instead of `aal2` under certain preconditions. This allows users to call the settings and whoami endpoint without a `aal2` session. An attacker would need to steal or guess a valid login OTP of a user with only OTP for login enabled and an incorrect `available aal` value stored to exploit this issue. Only 0.00066% of registered users on the Ory Network were affected, and most were test users. Their AAL values have been updated, and they are no longer vulnerable. **Recommendations** For versions prior to 1.3.0, disable the passwordless code login method if MFA is required. If that is not possible, check the session's `aal` to identify if the user has `aal1` or `aal2`.

**Name of the Vulnerable Software and Affected Versions** ORY Oathkeeper versions prior to v0.38.12-beta.1 **Description** The issue arises when a request is made to an endpoint requiring a specific scope, and the access token is granted with that scope, making introspection valid and caching the token. If a second request is made to an endpoint requiring a different scope before the cache expires, introspection will be valid regardless of whether the token is granted the new scope. The cache only validates the token's expiration date, ignoring whether the token has the proper scopes. This vulnerability was introduced due to insufficient test coverage during a code review. **Recommendations** To resolve the issue, update to version v0.38.12-beta.1 or later. As a temporary workaround, consider disabling caching for the `oauth2 introspection` authenticator, as this vulnerability does not exist when caching is disabled. Restrict access to the vulnerable `AuthenticatorOAuth2Introspection` function until a patch is available. Avoid using the `tokenFromCache()` function until the issue is resolved. Disable the cache when the scope strategy is `none` and the `requested scope` is not empty to prevent the cache from being used.

Name of the Vulnerable Software and Affected Versions: No specific software or versions are mentioned in the provided descriptions. Description: The issue arises due to improper validation of caller input. If the provided expected token is malformed, validation is silently disabled, causing any user-supplied token to be considered valid. This could potentially allow unauthorized access. Recommendations: At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** ORY Fosite versions 0.30.2 through 0.34.1 **Description** The issue allows an attacker to override the registered redirect URL by performing an OAuth flow and requesting a redirect URL that is to the loopback adapter. Attackers can provide custom URL query parameters to their loopback redirect URL, as well as override the host of the registered redirect URL. These attacks are only applicable in scenarios where the attacker has access over the loopback interface. **Recommendations** For versions 0.30.2 through 0.34.1, update to ORY Fosite v0.34.1 to resolve the issue. As a temporary workaround, consider restricting access to loopback interfaces to minimize the risk of exploitation. Avoid using custom URL query parameters in redirect URLs for loopback interfaces until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Hydra versions prior to 1.4.0+oryOS.17 **Description** The issue concerns Hydra, an OAuth2 Server and OpenID Certified OpenID Connect Provider written in Go. When using the client authentication method 'private key jwt', Hydra does not check the uniqueness of the `jti` value in the token, which can be used to prevent token reuse. Although exploiting this issue is somewhat difficult due to TLS protection against MITM attacks and the short expiry time of the JWT, it still poses a risk. **Recommendations** For versions prior to 1.4.0+oryOS.17, update to version 1.4.0+oryOS.17 to resolve the issue. As a temporary workaround, consider disabling the use of 'private key jwt' for client authentication. Alternatively, use short expiry times for the JWTs to minimize the window of opportunity for token replay attacks.