<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Uma — CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/tags/uma/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata — refreshed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Thu, 02 Apr 2026 13:16:27 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/tags/uma/feed.xml" rel="self" type="application/rss+xml"/><item><title>Keycloak UMA Policy Bypass Vulnerability (CVE-2026-4636)</title><link>https://feed.craftedsignal.io/briefs/2026-04-keycloak-uma-bypass/</link><pubDate>Thu, 02 Apr 2026 13:16:27 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2026-04-keycloak-uma-bypass/</guid><description>CVE-2026-4636 describes a vulnerability in Keycloak where an authenticated user with the uma_protection role can bypass User-Managed Access (UMA) policy validation, leading to unauthorized access to victim-owned resources.</description><content:encoded><![CDATA[<p>A vulnerability, identified as CVE-2026-4636, has been discovered in Keycloak, a popular open-source identity and access management solution. This flaw allows an authenticated user who possesses the <code>uma_protection</code> role to bypass User-Managed Access (UMA) policy validation. By exploiting this vulnerability, an attacker can manipulate policy creation requests to include resource identifiers that belong to other users. This circumvents the intended access controls and enables the attacker to gain unauthorized permissions to resources owned by victims. The scope of the attack is limited to Keycloak instances where UMA is enabled and users have the <code>uma_protection</code> role. This can lead to significant data breaches and unauthorized actions performed under the guise of legitimate users.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>An attacker authenticates to Keycloak with an account that has the <code>uma_protection</code> role.</li>
<li>The attacker initiates a request to create a new UMA policy.</li>
<li>The attacker crafts the policy creation request to include resource identifiers that belong to other users. This is done even though the URL path in the request specifies a resource owned by the attacker.</li>
<li>The UMA policy validation mechanism fails to properly verify the ownership of the included resource identifiers.</li>
<li>Keycloak creates the UMA policy, granting the attacker unauthorized permissions to the victim-owned resources.</li>
<li>The attacker obtains a Requesting Party Token (RPT) for the victim&rsquo;s resources using the newly created policy.</li>
<li>The attacker uses the RPT to access the victim&rsquo;s resources, potentially accessing sensitive information.</li>
<li>The attacker performs unauthorized actions on the victim&rsquo;s resources, leveraging the gained permissions.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful exploitation of CVE-2026-4636 allows an attacker to gain unauthorized access to resources managed by Keycloak. This can lead to the exposure of sensitive data, such as personal information, financial records, or confidential business documents. The number of affected users depends on the scope of the attacker&rsquo;s access and the number of resources they can compromise. The impact could range from individual account compromise to widespread data breaches affecting entire organizations relying on Keycloak for access control.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Apply the patch or upgrade to a version of Keycloak that resolves CVE-2026-4636 as soon as it becomes available.</li>
<li>Monitor Keycloak logs for suspicious UMA policy creation requests that include resource identifiers not owned by the requesting user. Create a Sigma rule based on webserver logs and filter for POST requests on <code>/auth/realms/&lt;realm&gt;/authz/protection/uma-policy/</code> with suspicious resource IDs in the body.</li>
<li>Implement additional access controls and validation mechanisms to verify the ownership of resource identifiers during UMA policy creation.</li>
<li>Review existing UMA policies to identify and remove any policies that may have been created maliciously using this vulnerability.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>keycloak</category><category>uma</category><category>policy-bypass</category><category>privilege-escalation</category></item></channel></rss>