CVSS: 4.4EPSS: 0%CPEs: 1EXPL: 0CVE-2024-45042 – Ory Kratos's `highest_available` setting does not properly respect code + mfa credentials
https://notcve.org/view.php?id=CVE-2024-45042
Ory Kratos is an identity, user management and authentication system for cloud services. Prior to version 1.3.0, given a number of preconditions, the `highest_available` setting will incorrectly assume that the identity’s highest available AAL is `aal1` even though it really is `aal2`. This means that the `highest_available` configuration will act as if the user has only one factor set up, for that particular user. This means that they can call the settings and whoami endpoint without a `aal2` session, even though that should be disallowed. An attacker would need to steal or guess a valid login OTP of a user who has only OTP for login enabled and who has an incorrect `available_aal` value stored, to exploit this vulnerability. • https://github.com/ory/kratos/security/advisories/GHSA-wc43-73w7-x2f5 • CWE-287: Improper Authentication •
CVSS: 7.5EPSS: 0%CPEs: 12EXPL: 0CVE-2021-32701 – Possible bypass of token claim validation when OAuth2 Introspection caching is enabled
https://notcve.org/view.php?id=CVE-2021-32701
ORY Oathkeeper is an Identity & Access Proxy (IAP) and Access Control Decision API that authorizes HTTP requests based on sets of Access Rules. When you make a request to an endpoint that requires the scope `foo` using an access token granted with that `foo` scope, introspection will be valid and that token will be cached. The problem comes when a second requests to an endpoint that requires the scope `bar` is made before the cache has expired. Whether the token is granted or not to the `bar` scope, introspection will be valid. A patch will be released with `v0.38.12-beta.1`. • https://github.com/ory/oathkeeper/commit/1f9f625c1a49e134ae2299ee95b8cf158feec932 https://github.com/ory/oathkeeper/pull/424 https://github.com/ory/oathkeeper/security/advisories/GHSA-qvp4-rpmr-xwrr • CWE-863: Incorrect Authorization •
CVSS: 6.1EPSS: 0%CPEs: 1EXPL: 0CVE-2020-15233 – OAuth2 Redirect URL validity does not respect query parameters and character casing for loopback addresses
https://notcve.org/view.php?id=CVE-2020-15233
ORY Fosite is a security first OAuth2 & OpenID Connect framework for Go. In Fosite from version 0.30.2 and before version 0.34.1, there is an issue in which an an attacker can override the registered redirect URL by performing an OAuth flow and requesting a redirect URL that is to the loopback adapter. Attackers can provide both custom URL query parameters to their loopback redirect URL, as well as actually overriding the host of the registered redirect URL. These attacks are only applicable in scenarios where the attacker has access over the loopback interface. This vulnerability has been patched in ORY Fosite v0.34.1. • https://github.com/ory/fosite/commit/cdee51ebe721bfc8acca0fd0b86b030ca70867bf https://github.com/ory/fosite/security/advisories/GHSA-rfq3-w54c-f9q5 • CWE-20: Improper Input Validation CWE-601: URL Redirection to Untrusted Site ('Open Redirect') •
CVSS: 6.1EPSS: 0%CPEs: 1EXPL: 0CVE-2020-15234 – Redirect URL matching ignores character casing
https://notcve.org/view.php?id=CVE-2020-15234
ORY Fosite is a security first OAuth2 & OpenID Connect framework for Go. In Fosite before version 0.34.1, the OAuth 2.0 Client's registered redirect URLs and the redirect URL provided at the OAuth2 Authorization Endpoint where compared using strings.ToLower while they should have been compared with a simple string match. This allows an attacker to register a client with allowed redirect URL https://example.com/callback. Then perform an OAuth2 flow and requesting redirect URL https://example.com/CALLBACK. Instead of an error (invalid redirect URL), the browser is redirected to https://example.com/CALLBACK with a potentially successful OAuth2 response, depending on the state of the overall OAuth2 flow (the user might still deny the request for example). • https://github.com/ory/fosite/commit/cdee51ebe721bfc8acca0fd0b86b030ca70867bf https://github.com/ory/fosite/security/advisories/GHSA-grfp-q2mm-hfp6 • CWE-20: Improper Input Validation CWE-178: Improper Handling of Case Sensitivity CWE-601: URL Redirection to Untrusted Site ('Open Redirect') •
CVSS: 8.1EPSS: 0%CPEs: 1EXPL: 1CVE-2020-15222 – Replay of private_key_jwt possible in ORY Fosite
https://notcve.org/view.php?id=CVE-2020-15222
In ORY Fosite (the security first OAuth2 & OpenID Connect framework for Go) before version 0.31.0, when using "private_key_jwt" authentication the uniqueness of the `jti` value is not checked. When using client authentication method "private_key_jwt", OpenId specification says the following about assertion `jti`: "A unique identifier for the token, which can be used to prevent reuse of the token. These tokens MUST only be used once, unless conditions for reuse were negotiated between the parties". Hydra does not seem to check the uniqueness of this `jti` value. This problem is fixed in version 0.31.0. • https://github.com/ory/fosite/commit/0c9e0f6d654913ad57c507dd9a36631e1858a3e9 https://github.com/ory/fosite/security/advisories/GHSA-v3q9-2p3m-7g43 https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication • CWE-287: Improper Authentication CWE-345: Insufficient Verification of Data Authenticity •