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
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
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. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation requires three specific conditions to align simultaneously: (1) the Keycloak deployment must have at least one confidential client configured to receive signed JWT introspection responses - this is a non-default client-level setting that must be explicitly enabled; (2) the attacker must possess valid client credentials (client_id and client_secret) for such a confidential client, satisfying the PR:L requirement in the CVSS vector; (3) the attacker must have access to a bearer token originally issued for a different client or audience to submit to the introspection endpoint. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) scores 6.5 Medium, which accurately reflects the threat model: network-reachable, low complexity, but requiring low-privilege access (a valid confidential client credential set). … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | An attacker operating as a legitimate confidential client in a shared Keycloak realm - for example, a SaaS tenant application with valid client credentials - submits a token originally issued to a different client (obtained via other means, such as a leaked log entry or shared storage) to the token introspection endpoint. Despite receiving an 'active: false' response indicating the token is not valid for their audience, the signed JWT body in the response still contains the full token claims of the target user, including roles, email address, and custom attributes. … |
| Remediation | 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. … Detailed patch versions, workarounds, and compensating controls in full report. |
Threat intelligence, references, and detailed analysis are available after sign-in.
More in Red Hat Build Of Keycloak
View allAccount takeover in Keycloak (Red Hat build of Keycloak, Red Hat Single Sign-On 7) arises because the IdP-initiated SAML
Account takeover in Red Hat Build of Keycloak allows an unauthenticated attacker to abuse the reset-credentials flow in
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 weakness CWE-862 – Missing Authorization
View allSame technique Authentication Bypass
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today