CVE-2026-37977: Keycloak CORS Information Disclosure Flaw

CVE-2026-37977 Overview

A Cross-Origin Resource Sharing (CORS) header injection vulnerability has been identified in Keycloak's User-Managed Access (UMA) token endpoint. This flaw allows a remote attacker to exploit improper origin validation by crafting a malicious JSON Web Token (JWT) with an attacker-controlled azp (authorized party) claim. The vulnerability arises because the Access-Control-Allow-Origin header is set based on the azp claim before the JWT signature is properly validated. This can result in information exposure from authorization server error responses and weaken origin isolation protections.

Critical Impact

Remote attackers can bypass CORS protections to expose low-sensitivity information from authorization server error responses when target clients are misconfigured with webOrigins: ["*"].

Affected Products

• Keycloak (versions unspecified)
• Red Hat Single Sign-On (SSO) implementations using Keycloak
• Applications utilizing Keycloak's UMA token endpoint with permissive webOrigins configuration

Discovery Timeline

• 2026-04-06 - CVE-2026-37977 published to NVD
• 2026-04-07 - Last updated in NVD database

Technical Details for CVE-2026-37977

Vulnerability Analysis

This vulnerability is classified under CWE-346 (Origin Validation Error), which occurs when a product does not properly verify that the source of data or communication is valid. In Keycloak's UMA token endpoint implementation, the azp claim extracted from a client-supplied JWT is used to populate the Access-Control-Allow-Origin response header prematurely—before the JWT's cryptographic signature is validated.

The attack requires specific preconditions: the target Keycloak client must be misconfigured with a wildcard web origins setting (webOrigins: ["*"]). When these conditions are met, an attacker can craft a JWT containing an arbitrary azp value. Even though the grant request will ultimately be rejected due to signature validation failure, the malicious origin value is still reflected in the CORS header of the error response.

This behavior enables an attacker to receive cross-origin error responses that would normally be blocked by browser same-origin policies. While the information disclosed is limited to authorization server error messages, this weakens the security boundary between origins and could be leveraged in more sophisticated attack chains.

Root Cause

The root cause is an improper order of operations in the UMA token endpoint request processing. The azp claim from the incoming JWT is extracted and used to set CORS headers before the JWT signature validation step completes. This violates the security principle that untrusted input should be validated before being used in security-relevant operations.

The vulnerable code path processes the azp claim to determine allowed origins for CORS preflight and actual responses, trusting this value without first verifying the JWT's integrity. This creates a window where attacker-controlled data influences HTTP response headers regardless of whether the request is ultimately authorized.

Attack Vector

The attack is network-based and can be executed remotely without authentication. An attacker crafts a malicious JWT with a specially chosen azp claim value set to their controlled origin. When this JWT is submitted to the vulnerable UMA token endpoint, the following sequence occurs:

1. The attacker's malicious origin from the azp claim is reflected in the Access-Control-Allow-Origin header
2. The JWT signature validation subsequently fails
3. An error response is returned with the attacker-controlled CORS header
4. The attacker's browser receives the error response content due to the permissive CORS header

This allows the attacker to observe error details that would normally be blocked by same-origin policy. The attack complexity is high because it requires the specific misconfiguration of webOrigins: ["*"] on the target client.

Detection Methods for CVE-2026-37977

Indicators of Compromise

• Unusual JWT submissions to UMA token endpoints with non-standard or suspicious azp claim values
• High volume of failed authentication attempts from single sources targeting /auth/realms/*/protocol/openid-connect/token endpoints
• CORS-related error responses being returned to origins not configured in Keycloak client settings
• Log entries showing JWT signature validation failures with atypical origin patterns

Detection Strategies

• Monitor Keycloak audit logs for repeated token endpoint failures with varying azp claims from the same source
• Implement anomaly detection for UMA token requests containing azp values that don't match registered client identifiers
• Review web server access logs for unusual patterns of requests to token endpoints with subsequent cross-origin requests
• Configure SIEM rules to alert on high-frequency authorization failures combined with external origin access

Monitoring Recommendations

• Enable detailed logging for Keycloak's UMA token endpoint to capture azp claim values in failed requests
• Deploy Web Application Firewall (WAF) rules to inspect JWT payloads for suspicious origin patterns in claims
• Implement rate limiting on token endpoints to reduce the impact of automated exploitation attempts
• Audit Keycloak client configurations to identify any instances of webOrigins: ["*"] that should be restricted

How to Mitigate CVE-2026-37977

Immediate Actions Required

• Audit all Keycloak client configurations and replace any webOrigins: ["*"] settings with explicit, trusted origin lists
• Review and restrict CORS policies to only allow known and trusted origins for each client application
• Monitor token endpoint logs for signs of exploitation attempts while awaiting official patches
• Consider implementing additional origin validation at the reverse proxy or load balancer level

Patch Information

Red Hat has acknowledged this vulnerability and is tracking it through their security response process. For official patch information and updates, refer to the Red Hat CVE-2026-37977 Advisory and Red Hat Bug Report #2455324. Organizations should monitor these resources for patch availability and apply updates as soon as they are released.

Workarounds

• Configure explicit allowed origins in Keycloak client settings instead of using wildcard (*) values
• Implement additional CORS validation at the reverse proxy layer to provide defense-in-depth
• Restrict network access to Keycloak token endpoints to trusted IP ranges where feasible
• Consider deploying a Web Application Firewall (WAF) with rules to validate JWT structure before forwarding requests

# Configuration example - Restrict webOrigins in Keycloak client configuration
# In Keycloak Admin Console or via API, update client settings:
# Replace:
#   "webOrigins": ["*"]
# With explicit origins:
#   "webOrigins": ["https://trusted-app.example.com", "https://api.example.com"]

# Using kcadm.sh to update client configuration:
kcadm.sh update clients/<client-id> \
  -r <realm-name> \
  -s 'webOrigins=["https://trusted-origin.example.com"]'