Description

CVE-2026-37977: When using the UMA token endpoint, Keycloak sets the Access-Control-Allow-Origin response header based on the azp claim from a client-provided JWT before validating the JWT signature. While the token grant itself is correctly rejected during validation, the CORS header has already been set in the response.

This allows a client to control which origin can read the error response cross-origin. The impact is limited to reading error messages - no tokens or user data are exposed.

Prerequisites:

• Client must be configured with webOrigins: ["*"] (non-default configuration)
• Only affects error responses, not successful token grants

Version Affected

26.5.6 and potentially other versions

Steps to Reproduce

1. Configure a Keycloak client with webOrigins: ["*"]
2. Create a JWT with the azp claim set to any origin (e.g., https://example.com)
3. Sign the JWT with any key (signature validation will fail later)
4. Send a POST request to /realms/{realm}/protocol/openid-connect/token with:
   • grant_type=urn:ietf:params:oauth:grant-type:uma-ticket
   • Include the crafted JWT
5. Inspect the response headers

Expected Behavior

The Access-Control-Allow-Origin header should only be set after JWT signature validation, or should be based on the client's configured origins rather than the unverified azp claim.

Actual Behavior

The Access-Control-Allow-Origin header reflects the value from the azp claim before signature verification, allowing the error response to be read cross-origin from any specified domain.

Additional Context

This issue has been assigned CVE-2026-37977 for tracking purposes.

The practical impact is limited because:

• Only error responses are affected
• No tokens or user data are exposed
• Requires non-default client configuration
• The token grant itself is correctly rejected

This issue was originally tracked in the private repository. Migrated by @ahus1.