Bug 2481845 (CVE-2026-9689)

Summary: CVE-2026-9689 keycloak: org.keycloak.protocol.oidc: HTTP Parameter Pollution in OIDC redirect URI allows response parameter duplication - #GHI-604
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: aschwart, aszczucz, boliveir, drichtar, mposolda, pjindal, rmartinc, security-response-team, ssilvert, sthorger, vmuzikar
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in Keycloak, an open-source identity and access management solution. When a client application is configured to accept broad redirect Uniform Resource Identifiers (URIs), a remote attacker can manipulate the authentication process by crafting a special web address. If a user clicks this link, the client application might incorrectly prioritize attacker-controlled information over legitimate data. This vulnerability, known as HTTP parameter pollution, could allow an attacker to bypass security measures or gain unauthorized access to resources.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-05-27 09:27:53 UTC
Keycloak accepts redirect URIs containing pre-loaded OIDC response parameters (iss, code, state, session_state) when wildcard redirect URIs are configured on a client. After successful authentication, OIDCRedirectUriBuilder.addParam() appends Keycloak's own response parameters without checking for duplicates, resulting in a polluted redirect URL with duplicate parameters. Client applications using first-wins parameter parsing may trust attacker-controlled values. Successful exploitation requires - a client must have a wildcard redirect uri registered (e.g., http://localhost:8080/*) - the victim must follow an attacker-crafted authorization url - the client application must use a first-wins parsing strategy for duplicate query parameters. This issue affects All versions.