Skip to main content

CVE-2024-8883: Redhat Build Of Keycloak CSRF Vulnerability

CVE-2024-8883 is a CSRF flaw in Redhat Build Of Keycloak that enables attackers to redirect users and expose authorization codes, potentially leading to session hijacking. This post covers technical details, affected versions, impact, and mitigation.

Updated:

CVE-2024-8883 Overview

CVE-2024-8883 is an open redirect vulnerability in Red Hat Keycloak that stems from a misconfiguration in the Valid Redirect URI validation logic. When a client is configured with http://localhost or http://127.0.0.1 as a Valid Redirect URI, an attacker can craft a malicious authorization request that redirects users to an arbitrary external URL. This exposure allows sensitive OAuth 2.0 and OpenID Connect data, including authorization codes, to be leaked to attacker-controlled hosts. The vulnerability is classified under CWE-601: URL Redirection to Untrusted Site and affects Keycloak-based identity products across Red Hat's portfolio.

Critical Impact

Successful exploitation can leak OAuth authorization codes to attacker-controlled destinations, enabling session hijacking and account takeover of federated users.

Affected Products

  • Red Hat Build of Keycloak
  • Red Hat Single Sign-On 7.6
  • Red Hat OpenShift Container Platform (versions 4.9 through 4.12, including IBM Z, LinuxONE, and Power variants)

Discovery Timeline

  • 2024-09-19 - CVE-2024-8883 published to the National Vulnerability Database
  • 2024-09-19 - Red Hat releases initial security advisories (RHSA-2024:6878 through RHSA-2024:6890)
  • 2026-08-04 - Last updated in NVD database

Technical Details for CVE-2024-8883

Vulnerability Analysis

The flaw resides in Keycloak's redirect URI validation performed by the RedirectUtils class within the OpenID Connect (OIDC) protocol handler. Keycloak permits clients to register Valid Redirect URIs to constrain where authorization codes and tokens may be returned after authentication. When an administrator registers http://localhost or http://127.0.0.1 as a valid redirect target, the validator treats these as loopback destinations and applies relaxed matching. An attacker can abuse this relaxed matching to supply a redirect URI that satisfies the validator while pointing to an external, attacker-controlled host. The vulnerability is significant for public OAuth clients such as command-line tools and native desktop applications, which commonly register loopback URIs to receive authorization codes.

Root Cause

The root cause is insufficient hostname validation in the redirect URI comparison logic. The validator does not strictly enforce that the resolved host of an incoming redirect_uri parameter matches the loopback interface of the requesting client. Instead, the pattern-matching behavior around registered loopback URIs allows a crafted redirect_uri to bypass the intended restriction. See the Keycloak RedirectUtils source for the affected code path.

Attack Vector

An attacker crafts an authorization request URL targeting a vulnerable Keycloak realm and client, substituting a malicious redirect_uri value that passes the validator's loopback check but resolves to an attacker host. The attacker distributes this URL through phishing, malicious links, or compromised web content. When a victim clicks the link and authenticates, Keycloak returns to the attacker's URL with the OAuth authorization code appended. The attacker then exchanges the code for tokens at the token endpoint if the client uses the implicit or public client flow without Proof Key for Code Exchange (PKCE) verifier binding. User interaction is required, and no privileges are needed on the Keycloak server itself.

See the Red Hat CVE report for CVE-2024-8883 for the vendor's technical description.

Detection Methods for CVE-2024-8883

Indicators of Compromise

  • Authorization requests where the redirect_uri parameter contains a hostname that is not localhost, 127.0.0.1, or ::1 but still passes validation against a client configured with a loopback Valid Redirect URI.
  • Anomalous outbound HTTP traffic from authenticated users to unfamiliar domains immediately after successful Keycloak login events.
  • Keycloak audit log entries showing CODE_TO_TOKEN or LOGIN events with unusual redirect_uri values in the event details.

Detection Strategies

  • Enumerate all Keycloak clients across every realm and identify those with Valid Redirect URIs containing http://localhost or http://127.0.0.1, treating each as a candidate for exploitation.
  • Parse Keycloak event logs and alert on authorization requests where the fully qualified host of the redirect_uri does not resolve to a loopback address despite matching a loopback-configured client.
  • Correlate authentication events with subsequent web proxy logs to identify redirects that leave the corporate perimeter following a successful Keycloak login.

Monitoring Recommendations

  • Enable Keycloak event logging with EVENT and ADMIN_EVENT categories and forward records to a centralized log platform for analysis.
  • Monitor Red Hat Single Sign-On and Keycloak container images for version metadata to confirm patched builds are running in production.
  • Track OAuth token issuance patterns and alert on abnormal spikes in code grant exchanges from IP ranges that do not match user endpoints.

How to Mitigate CVE-2024-8883

Immediate Actions Required

  • Apply the Red Hat security updates referenced in advisories RHSA-2024:6878 through RHSA-2024:6890, and the subsequent RHSA-2024:8823, RHSA-2024:8824, RHSA-2024:8826, RHSA-2024:10385, and RHSA-2024:10386 for your platform.
  • Audit every realm and replace loopback Valid Redirect URIs with fully qualified, port-specific URIs such as http://127.0.0.1:8080/callback where feasible.
  • Enforce PKCE for all public OAuth clients so that a leaked authorization code cannot be exchanged without the original verifier.

Patch Information

Red Hat has published fixed builds for Red Hat Build of Keycloak, Red Hat Single Sign-On 7.6, and affected OpenShift Container Platform releases. Refer to the Red Hat CVE page for CVE-2024-8883 and Bugzilla #2312511 for the complete list of patched package versions and platform-specific errata.

Workarounds

  • Remove http://localhost and http://127.0.0.1 entries from the Valid Redirect URIs field of every client that does not strictly require loopback callbacks.
  • Where loopback redirects are required for native or CLI clients, restrict the registered URI to include a fixed path and, where possible, a fixed port to reduce the attacker's ability to control the callback target.
  • Shorten authorization code lifetimes in realm settings so that any leaked code has minimal window for exchange.
bash
# Configuration example: audit Keycloak clients for loopback redirect URIs using kcadm.sh
/opt/keycloak/bin/kcadm.sh config credentials \
  --server https://sso.example.com \
  --realm master \
  --user admin

/opt/keycloak/bin/kcadm.sh get clients -r <realm-name> \
  --fields 'clientId,redirectUris' \
  | grep -E 'localhost|127\.0\.0\.1'

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.