Red Hat Keycloak CVE-2026-7500

Exploitation requires that Keycloak is started with the --features-disabled=account,account-api flag AND the attacker possesses valid authentication credentials with sufficient permissions to invoke the Account REST API (PR:L in CVSS indicates low privilege level, such as a standard user or tenant account). The five unprotected endpoints under /account/v1alpha1/ remain accessible because they lack the checkAccountApiEnabled() guard; four other endpoints in the same REST service class do include this guard, confirming the inconsistency. Exploitation is limited to the scope of a single user's account data (Scope:U in CVSS) and does not grant system-wide or administrative access. Non-exploitation factors include: (1) if Keycloak is deployed without the feature-disable flag, the Account API is intentionally enabled and this is not a vulnerability; (2) if the attacker lacks authentication credentials, the endpoints cannot be accessed (AV:N/AC:L/PR:L means network access is possible but authentication is mandatory); (3) if the Keycloak instance is deployed with the five vulnerable endpoints isolated via network controls (reverse proxy deny rules), access can be prevented.

CVSS 5.4 (Medium) with vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L reflects network-accessible endpoints requiring only low-privilege authentication (PR:L), with limited confidentiality and integrity impact (C:L/I:L) and no availability impact. The CVSS score appropriately weights this as moderate risk because exploitation requires valid credentials and produces partial rather than critical data exposure. The attack vector is network-based with low complexity, increasing accessibility; however, the requirement for authenticated access (PR:L) and limited scope of impact (single user's account data, not system-wide) constrains real-world threat severity. This is NOT a high-risk vulnerability despite network accessibility - it primarily affects multi-tenant environments where you must prevent specific user personas (e.g., tenants with restricted roles) from accessing account APIs. The underlying concern is configuration bypass: administrators explicitly disabled the API for security reasons (e.g., per compliance requirements), and five endpoints circumvent that decision. In single-tenant or fully-trusted deployments, this vulnerability may have minimal practical impact.

An authenticated user with low-privilege credentials (e.g., a tenant or developer account in a multi-tenant Keycloak instance) can craft HTTP requests to five unguarded endpoints under /account/v1alpha1/ to read account metadata or modify account attributes even though the Keycloak administrator explicitly disabled the Account API via --features-disabled=account,account-api to prevent such access. For example, a user could send a GET request to /account/v1alpha1/profile to retrieve account information or a POST request to update account settings, bypassing the feature-disable flag.