What is the CVSS score of CVE-2026-16089?

CVE-2026-16089 has a CVSS 3.1 base score of 5.9 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:L/A:N. EPSS exploitation probability: 0.2%.

Red Hat Keycloak CVE-2026-16089

EUVD-2026-45176 MEDIUM

Session Fixation (CWE-384)

2026-07-17 redhat

GHSA-63wm-fvw8-h2hp

Information Disclosure Red Hat Session Fixation Red Hat Build Of Keycloak Red Hat Jboss Enterprise Application Platform Expansion Pack Red Hat Single Sign On 7 Red Hat Data Grid 8 Red Hat

5.9

CVSS 3.1 · NVD

Severity by source

Vendor (redhat) PRIMARY

MEDIUM

qualitative

NVD

5.9 MEDIUM

AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:L/A:N

vuln.today AI

5.4 MEDIUM

Network-delivered but requires code interception (AC:H) and a low-privilege attacker position (PR:L); victim must initiate OAuth flow (UI:R); token issuance yields high confidentiality impact with minor integrity impact from cross-client redemption.

3.1 AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:L/A:N

4.0 AV:N/AC:H/AT:P/PR:L/UI:A/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N

Red Hat

5.4 MEDIUM

qualitative

Primary rating from Vendor (redhat).

CVSS VectorNVD

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

High

Integrity

Low

Availability

None

Lifecycle Timeline

CVSS changed

Aug 09, 2026 - 15:07 NVD

5.4 (MEDIUM) 5.9 (MEDIUM)

Analysis Generated

Jul 17, 2026 - 15:17 vuln.today

CVE Published

Jul 17, 2026 - 14:15 cve.org

MEDIUM 5.4

DescriptionNVD

A flaw was found in the keycloak-services component of Red Hat Build of Keycloak. The issue occurs because OAuth 2.0 authorization codes are not properly bound to the client that originally requested them. An attacker who can intercept an authorization code can modify it to be redeemed by their own client, potentially allowing them to obtain access tokens for a victim's identity.

AnalysisAI

Authorization code injection in Red Hat Build of Keycloak's keycloak-services component enables a network-positioned attacker to hijack OAuth 2.0 flows by intercepting and cross-client redeeming authorization codes. Because codes are not cryptographically bound to the originating client, an attacker who obtains a victim's in-flight code can submit it using their own registered client credentials and receive access tokens tied to the victim's identity. No public exploit has been identified at time of analysis, and the CVSS AC:H rating reflects the non-trivial code interception prerequisite that constrains opportunistic exploitation.

Technical ContextAI

The vulnerability resides in the keycloak-services component of Red Hat Build of Keycloak, an enterprise-grade identity and access management platform distributed by Red Hat and built on the open-source Keycloak project. The root cause is the absence of cryptographic binding between an OAuth 2.0 authorization code and the specific client that initiated the authorization request - a control that RFC 7636 (PKCE, Proof Key for Code Exchange) and the OAuth 2.0 Security Best Current Practice (RFC 9700) are designed to enforce. Without this binding, a code legitimately issued to Client A can be submitted to the token endpoint by Client B and honored by the server. Affected product families per CPE data include Red Hat Build of Keycloak, Red Hat Single Sign-On 7, Red Hat JBoss Enterprise Application Platform Expansion Pack, and Red Hat Data Grid 8. No CWE was formally assigned; the root cause maps conceptually to insufficient authorization logic in the OAuth token issuance path.

RemediationAI

Patch available per vendor advisory - administrators should apply the update published at https://access.redhat.com/security/cve/CVE-2026-16089 as the primary remediation; no specific fixed version number is confirmed in the available data, so the Red Hat advisory must be monitored directly for the patched release. As a direct compensating control, enforce PKCE (Proof Key for Code Exchange) for all OAuth clients registered in Keycloak - this cryptographically binds the authorization code to the initiating client session and directly blocks cross-client code redemption, though it requires all OAuth clients to implement PKCE support, which may break legacy integrations. Additionally, audit all registered OAuth clients for overly permissive redirect_uri patterns that could enable code interception via open redirects, since tightening these removes a common code-leakage vector. Reducing the 'OAuth 2.0 authorization code lifespan' in Keycloak realm settings shortens the interception window but does not eliminate the underlying binding flaw. Restricting the Keycloak authorization and token endpoints to trusted network segments further reduces exposure for the AC:H interception prerequisite.