EUVD-2026-45222
GHSA-jmhg-9c54-p575
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
PR:L reflects mandatory valid client credentials; C:L/I:L captures token issuance under bypassed policy; A:N as no availability impact is described.
Primary rating from Vendor (redhat).
CVSS VectorVendor: redhat
Lifecycle Timeline
2DescriptionCVE.org
Keycloak provides a mechanism called Client Policies to enforce security requirements on clients, such as requiring them to use signed JWTs for authentication. A flaw was discovered where this enforcement can be bypassed. An attacker with valid client credentials can provide a fake, unsigned assertion header that tricks the system into thinking the policy requirements have been met. This allows the attacker to authenticate using simpler methods like a client secret even when the administrator has mandated more secure, signed assertions.
AnalysisAI
Keycloak's Client Policies enforcement mechanism - designed to mandate stronger OAuth/OIDC client authentication such as signed JWTs (RFC 7523) - can be bypassed by any attacker who already holds valid client credentials. By supplying a crafted, unsigned assertion header in the token request, the attacker causes Keycloak to evaluate policy compliance as satisfied without performing cryptographic verification, allowing authentication to proceed via a weaker method such as a plain client secret. No public exploit code has been identified and this vulnerability is not listed in CISA KEV; however, the integrity impact is meaningful for organizations that deployed Client Policies specifically to harden their authentication security posture, as those controls are silently neutralized.
Technical ContextAI
Keycloak implements OAuth 2.0 and OpenID Connect, and its Client Policies framework allows realm administrators to enforce specific security profiles on registered clients - for example, mandating mutual TLS or requiring signed JWT client authentication per RFC 7523 (private_key_jwt). The root cause is classified as CWE-807 (Reliance on Untrusted Inputs in a Security Decision): the policy compliance check inspects an attacker-controllable assertion header field to determine whether the signed-JWT requirement is satisfied, rather than coupling that decision to a verified cryptographic operation. Because the header can be forged without a private key, the enforcement gate is decoupled from the cryptographic guarantee it is supposed to represent. The CPE strings confirm the flaw spans Red Hat Build of Keycloak (multiple release lines), Red Hat Single Sign-On 7, Red Hat JBoss EAP Expansion Pack, and Red Hat Data Grid 8, indicating the underlying Keycloak library version carries the flaw across several Red Hat product lines.
RemediationAI
Consult the Red Hat security advisory at https://access.redhat.com/security/cve/CVE-2026-16093 and the associated Bugzilla report at https://bugzilla.redhat.com/show_bug.cgi?id=2501729 for patched package versions; no exact fixed version number is confirmed in the currently available intelligence, so checking the advisory directly is mandatory before acting. Upstream fix availability in community Keycloak releases should also be verified via the Keycloak GitHub project. As an immediate compensating control while a patch is being evaluated, administrators can audit all clients configured with Client Policies requiring signed JWT authentication and validate through access logs whether any token requests are arriving with unusual or unsigned assertion headers. Additionally, scoping client credentials tightly - ensuring client secrets are rotated and not shared - limits the blast radius if credentials were already exposed. There is no feasible workaround that preserves the policy enforcement intent without patching, since the flaw is in the enforcement logic itself.
More in Red Hat Build Of Keycloak
View allAccount takeover in Red Hat Build of Keycloak allows an unauthenticated attacker to abuse the reset-credentials flow in
Account takeover in Keycloak (Red Hat build of Keycloak, Red Hat Single Sign-On 7) arises because the IdP-initiated SAML
Authentication bypass in Red Hat Build of Keycloak (and Red Hat Single Sign-On 7) lets an unauthenticated attacker forge
Privilege escalation in Red Hat Build of Keycloak's Dynamic Client Registration (DCR) grants an attacker with low-privil
Authorization bypass in the Keycloak Policy Enforcer allows any authenticated user to circumvent all enforced access con
URI normalization bypass in Keycloak's Authorization Services PathMatcher allows authenticated low-privilege users to re
Privilege escalation in Keycloak's Dynamic Client Registration (DCR) component allows attackers with standard user accou
Token exchange in Keycloak bypasses Google Workspace domain allowlist restrictions, enabling any valid Google account ho
Signature-verification bypass in Keycloak (and Red Hat's Keycloak-based products such as Red Hat Single Sign-On 7 and Re
Tenant-restriction bypass in Keycloak's Microsoft identity provider integration allows attackers holding any valid Micro
Session hijacking via SAML assertion replay in Keycloak's SAML broker component allows adjacent-network attackers to aut
Open redirect in Red Hat build of Keycloak permits remote attackers to send victims to attacker-controlled hosts by abus
Same technique Denial Of Service
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today