EUVD-2026-51482
GHSA-jg59-c35g-76r8
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
PR:L reflects mandatory confidential client authentication; C:H reflects full JWT claim exposure; I:N and A:N because no write or availability impact exists.
Primary rating from Vendor (redhat).
CVSS VectorVendor: redhat
Lifecycle Timeline
2DescriptionCVE.org
A flaw was found in the OIDC token introspection endpoint of the keycloak-services component. Keycloak is an open-source identity and access management solution used to secure modern applications and services. The issue occurs when a confidential client, configured to receive signed JWT introspection responses, attempts to introspect a token issued for a different audience. Although the endpoint correctly identifies the token as inactive for that client, it still returns the full set of token claims within a signed JWT field. This allows an unauthorized client to bypass audience-based restrictions and access sensitive information contained in the token.
AnalysisAI
Keycloak's OIDC token introspection endpoint incorrectly discloses the full set of JWT claims to confidential clients inspecting tokens that were not issued for them. Any confidential client configured to receive signed JWT introspection responses can submit a foreign token, receive an 'inactive' status confirmation, and simultaneously receive the complete signed JWT payload containing sensitive user attributes and claims - effectively bypassing the audience isolation that OIDC introspection is designed to enforce. No active exploitation has been confirmed (not listed in CISA KEV), and no public proof-of-concept code has been identified at time of analysis, but the low attack complexity and network accessibility via a standard API endpoint make this a meaningful confidentiality risk in multi-tenant or multi-client Keycloak deployments.
Technical ContextAI
Keycloak implements OAuth 2.0 Token Introspection (RFC 7662) within its keycloak-services component. When a confidential client is configured to receive signed JWT introspection responses - a non-default but supported Keycloak feature - the endpoint is expected to return only the 'active: false' indicator for tokens belonging to different audiences. CWE-862 (Missing Authorization) describes the root cause: the authorization check determining whether to suppress claim data in the signed JWT wrapper is absent or incomplete, allowing the JWT claims sub-object to be populated even when the token is flagged inactive for the requesting client. Affected products per CPE data include cpe:2.3:a:red_hat:red_hat_build_of_keycloak, cpe:2.3:a:red_hat:red_hat_data_grid_8, cpe:2.3:a:red_hat:red_hat_jboss_enterprise_application_platform_expansion_pack, and cpe:2.3:a:red_hat:red_hat_single_sign-on_7. CPE version ranges are all wildcards, meaning no specific fixed version boundary is disclosed in the available data.
RemediationAI
Consult the Red Hat security advisory at https://access.redhat.com/security/cve/CVE-2026-18208 for vendor-released patch availability; no specific fixed version number is confirmed in the data available at time of analysis. Until a patch is applied, organizations should assess whether the signed JWT introspection response format is required for any confidential client - if not, disabling signed JWT introspection responses for all clients eliminates this specific attack surface with minimal functional impact. Additionally, restrict token introspection endpoint access (typically /realms/{realm}/protocol/openid-connect/token/introspect) to only explicitly authorized internal service accounts via network policy or Keycloak client authorization policies, reducing the pool of principals capable of exploiting cross-audience claim disclosure. In multi-tenant deployments where confidential clients belong to different trust domains, consider isolating them into separate Keycloak realms to enforce hard audience boundaries at the realm level rather than relying solely on endpoint-level checks.
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
Mismatched handling of the HTTP/1 absolute-form request authority in Red Hat build of Quarkus and other affected Red Hat
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
Same weakness CWE-862 – Missing Authorization
View allSame technique Authentication Bypass
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today