Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact fosite#400 (released as v0.30.2) introduced a new feature for handling redirect URLs pointing to loopback interfaces (rfc8252#section-7.3). As part of that change new behavior was introduced which failed to respect the redirect URL's (only for loopback interfaces!) query parameters 1. Registering a client with allowed redirect URL http://127.0.0.1/callback 2. Performing OAuth2 flow and requesting redirect URL http://127.0.0.1/callback?bar=foo 3. Instead of an error, the browser is redirected to http://127.0.0.1/callback?bar=foo with a potentially successful OAuth2 response. as well as the host parameter (as long as the host is a loopback interface): 1. Registering a client with allowed redirect URL https://example.com/callback 2. Performing OAuth2 flow and requesting redirect URL http://127.0.0.1/callback 3. Instead of an error, the browser is redirected to http://127.0.0.1/callback with a potentially successful OAuth2 response. These bugs are only applicable in scenarios…
Recommended action: Upgrade to 0.34.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Before version v0.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: 1. Registering a client with allowed redirect URL https://example.com/callback 2. Performing OAuth2 flow and requesting redirect URL https://example.com/CALLBACK 3. 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).
Recommended action: Upgrade to 0.34.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When using client authentication method "privatekeyjwt" [[1]](https://openid.net/specs/openid-connect-core-10.html#ClientAuthentication), 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. Here is me sending the same token request twice, hence with the same jti assertion, and getting two access tokens: Patches This issue is patched in 0.31.0. Workarounds Do not allow clients to use privatekeyjwt. References https://openid.net/specs/openid-connect-core-10.html#ClientAuthentication
Recommended action: Upgrade to 0.31.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The TokenRevocationHandler ignores errors coming from the storage. This can lead to unexpected 200 status codes indicating successful revocation while the token is still valid. Whether an attacker can use this for her advantage depends on the ability to trigger errors in the store. References RFC 7009 states that a 503 HTTP code must be returned when the server has a problem.
Recommended action: Upgrade to 0.34.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.