CVE-2026-3190: Keycloak Information Disclosure Flaw

CVE-2026-3190 Overview

A flaw was found in Keycloak's User-Managed Access (UMA) 2.0 Protection API endpoint for permission tickets. The endpoint fails to enforce the uma_protection role check, allowing any authenticated user with a token issued for a resource server client—even without the uma_protection role—to enumerate all permission tickets in the system. This authorization bypass vulnerability leads to partial information disclosure.

Critical Impact

Authenticated attackers can enumerate all permission tickets in the Keycloak system without proper authorization, potentially exposing sensitive access control information and enabling further reconnaissance attacks.

Affected Products

• Keycloak (specific affected versions to be determined by vendor advisory)
• Red Hat Single Sign-On (based on Keycloak)
• Products utilizing Keycloak UMA 2.0 Protection API

Discovery Timeline

• 2026-03-26 - CVE-2026-3190 published to NVD
• 2026-03-26 - Last updated in NVD database

Technical Details for CVE-2026-3190

Vulnerability Analysis

This vulnerability represents a Broken Access Control flaw (CWE-280: Improper Handling of Insufficient Permissions or Privileges) in Keycloak's implementation of the UMA 2.0 Protection API. The core issue lies in the permission ticket endpoint's failure to validate that the requesting user possesses the required uma_protection role before processing requests.

In a properly secured implementation, the UMA 2.0 Protection API should restrict access to authorized resource servers that have been explicitly granted the uma_protection role. However, due to this flaw, the authorization check is either missing or improperly implemented, allowing any authenticated user with a valid token issued for a resource server client to query and enumerate permission tickets.

The vulnerability requires network access and low-privilege authentication, meaning an attacker must first obtain a valid authentication token. The impact is limited to confidentiality—there is no direct integrity or availability impact. However, the exposed information could facilitate further attacks by revealing the permission structure and access patterns within the system.

Root Cause

The root cause is insufficient authorization validation in the UMA 2.0 Protection API permission ticket endpoint. The endpoint accepts requests from authenticated users without verifying that the caller has been assigned the uma_protection role, which is the designated role for resource server clients that should have access to protection API functionality. This missing role check allows any authenticated client to bypass the intended access restrictions.

Attack Vector

The attack is conducted over the network against the Keycloak UMA 2.0 Protection API endpoint. An attacker with legitimate credentials for a resource server client can craft API requests to the permission ticket endpoint. Despite lacking the uma_protection role, these requests are processed, returning permission ticket information that should only be accessible to properly authorized protection API clients.

The attack flow involves:

1. Obtaining a valid authentication token for any resource server client in the Keycloak realm
2. Sending requests to the UMA 2.0 Protection API permission ticket endpoint
3. Enumerating permission tickets without the required uma_protection role authorization

For detailed technical information, refer to the Red Hat CVE-2026-3190 Advisory and Red Hat Bug Report #2442572.

Detection Methods for CVE-2026-3190

Indicators of Compromise

• Unusual or high-volume requests to the UMA 2.0 Protection API permission ticket endpoints from clients that should not have protection API access
• API requests to permission ticket endpoints from users or service accounts lacking the uma_protection role
• Unexpected enumeration patterns in Keycloak access logs showing systematic queries to permission ticket resources

Detection Strategies

• Implement audit logging for all UMA 2.0 Protection API requests and correlate with role assignments to identify unauthorized access attempts
• Monitor Keycloak authentication logs for token usage patterns that indicate permission ticket enumeration without the uma_protection role
• Deploy API gateway rules to flag requests to protection API endpoints from clients without documented authorization requirements

Monitoring Recommendations

• Enable detailed access logging on Keycloak instances, particularly for UMA 2.0 Protection API endpoints
• Configure alerts for unusual query patterns or rate spikes on permission ticket endpoints
• Regularly audit client role assignments to ensure only authorized resource servers possess the uma_protection role

How to Mitigate CVE-2026-3190

Immediate Actions Required

• Review the Red Hat CVE-2026-3190 Advisory for official patch information and apply updates when available
• Audit all clients with access to UMA 2.0 Protection API functionality and verify appropriate role assignments
• Implement network-level restrictions to limit access to protection API endpoints to known authorized systems
• Enable enhanced logging on Keycloak instances to detect potential exploitation attempts

Patch Information

Consult the Red Hat CVE-2026-3190 Advisory and Red Hat Bug Report #2442572 for official patch release information and remediation guidance. Apply vendor-provided security updates as soon as they become available.

Workarounds

• Implement API gateway or reverse proxy rules to enforce additional authorization checks on UMA 2.0 Protection API endpoints before requests reach Keycloak
• Restrict network access to Keycloak admin and protection API endpoints using firewall rules or network segmentation
• Consider temporarily disabling UMA 2.0 Protection API functionality if not actively required, until patches are applied

# Example: Restrict access to Keycloak protection API at network level
# Add to firewall or reverse proxy configuration
# Only allow known authorized resource server IPs to access protection endpoints
iptables -A INPUT -p tcp --dport 8080 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 8080 -j DROP