Package Instance

Duplicate Advisory: Keycloak-services SMTP Inject Vulnerability
### Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-m4j5-5x4r-2xp9. This link is maintained to preserve external references.

### Original Description
A vulnerability was found in Keycloak-services. Special characters used during e-mail registration may perform SMTP Injection and unexpectedly send short unwanted e-mails. The email is limited to 64 characters (limited local part of the email), so the attack is limited to very shorts emails (subject and little data, the example is 60 chars). This flaw's only direct consequence is an unsolicited email being sent from the Keycloak server. However, this action could be a precursor for more sophisticated attacks.

Keycloak phishing attack via email verification step in first login flow
There is a flaw with the first login flow where, during a IdP login, an attacker with a registered account can initiate the process to merge accounts with an existing victim's account. The attacker will subsequently be prompted to "review profile" information, which allows the the attacker to modify their email address to that of a victim's account. This triggers a verification email sent to the victim's email address. If the victim clicks the verification link, the attacker can gain access to the victim's account. While not a zero-interaction attack, the attacker's email address is not directly present in the verification email content, making it a potential phishing opportunity. 

This issue has been fixed in versions 26.0.13, 26.2.6, and 26.3.0.

Keycloak's missing timestamp validation allows attackers to extend SAML response validity periods
A flaw was found in Keycloak's SAML brokering functionality. When Keycloak is configured as a client in a Security Assertion Markup Language (SAML) setup, it fails to validate the `NotOnOrAfter` timestamp within the `SubjectConfirmationData`. This allows an attacker to delay the expiration of SAML responses, potentially extending the time a response is considered valid and leading to unexpected session durations or resource consumption.

Keycloak vulnerable to session takeovers due to reuse of session identifiers
A flaw was found in Keycloak. In Keycloak where a user can accidentally get access to another user's session if both use the same device and browser. This happens because Keycloak sometimes reuses session identifiers and doesn’t clean up properly during logout when browser cookies are missing. As a result, one user may receive tokens that belong to another user.

Duplicate Advisory: Keycloak Open Redirect vulnerability
# Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-w8gr-xwp4-r9f7. This link is maintained to preserve external references.

# Original Description
A misconfiguration flaw was found in Keycloak. This issue can allow an attacker to redirect users to an arbitrary URL if a 'Valid Redirect URI' is set to http://localhost or http://127.0.0.1, enabling sensitive information such as authorization codes to be exposed to the attacker, potentially leading to session hijacking.

Keycloak: Information disclosure of disabled user attributes via administrative endpoint
A flaw was found in Keycloak. An authenticated user with the view-users role could exploit a vulnerability in the UserResource component. By accessing a specific administrative endpoint, this user could improperly retrieve user attributes that were configured to be hidden. This unauthorized information disclosure could expose sensitive user data.

Duplicate Advisory: Keycloak vulnerable to two factor authentication bypass
# Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-5jfq-x6xp-7rw2. This link is maintained to preserve external references.

# Original Description
A flaw was found in Keycloak. The org.keycloak.authorization package may be vulnerable to circumventing required actions, allowing users to circumvent requirements such as setting up two-factor authentication.

Keycloak Denial of Service (DoS) Vulnerability via JWT Token Cache
A flaw was found in Keycloak. When the configuration uses JWT tokens for authentication, the tokens are cached until expiration. If a client uses JWT tokens with an excessively long expiration time, for example, 24 or 48 hours, the cache can grow indefinitely, leading to an OutOfMemoryError. This issue could result in a denial of service condition, preventing legitimate users from accessing the system.