<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Thu, 08 Oct 2026 07:51:50 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-293232</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-293232</link>
      <description>EUVD-2026-293232</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-293232</guid>
    </item>
    <item>
      <title>fkie_cve-2026-41166</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-41166</link>
      <description>&lt;p&gt;OpenRemote is an open-source internet-of-things platform. Prior to version 1.22.1, a user who has `write:admin` in one Keycloak realm can call the Manager API to update Keycloak realm roles for users in another realm, including `master`. The handler uses the `{realm}` path segment when talking to the identity provider but does not check that the caller may administer that realm. This could result in a privilege escalation to `master` realm administrator if the attacker controls any user in `master` realm. Version 1.22.1 fixes the issue.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;OpenRemote is an open-source internet-of-things platform. Prior to version 1.22.1, a user who has `write:admin` in one Keycloak realm can call the Manager API to update Keycloak realm roles for users in another realm, including `master`. The handler uses the `{realm}` path segment when talking to the identity provider but does not check that the caller may administer that realm. This could result in a privilege escalation to `master` realm administrator if the attacker controls any user in `master` realm. Version 1.22.1 fixes the issue.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-41166</guid>
    </item>
    <item>
      <title>GHSA-49vv-25qx-mg44 — OpenRemote has Improper Access Control via updateUserRealmRoles function</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-49vv-25qx-mg44</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: io.openremote:openremote-manager&lt;/p&gt;
&lt;p&gt;### Summary
A user who has `write:admin` in one Keycloak realm can call the Manager API to update **Keycloak realm roles** for users in **another** realm, including **`master`**. The handler uses the `{realm}` path segment when talking to the identity provider but does not check that the caller may administer that realm. This could result in a privilege escalation to `master` realm administrator if the attacker controls any user in `master` realm.&lt;/p&gt;
&lt;p&gt;### Details
In `manager/src/main/java/org/openremote/manager/security/UserResourceImpl.java`, there is no check to validate if the caller should be able to administer a realm they&amp;#39;re trying to update.&lt;/p&gt;
&lt;p&gt;```340:353:manager/src/main/java/org/openremote/manager/security/UserResourceImpl.java
    @Override
    public void updateUserRealmRoles(RequestParams requestParams, String realm, String userId, String[] roles) {
        try {
            identityService.getIdentityProvider().updateUserRealmRoles(
                realm,
                userId,
                roles);
        } catch (ClientErrorException ex) {
            ex.printStackTrace(System.out);
            throw new WebApplicationException(ex.getCause(), ex.getResponse().getStatus());
        } catch (Exception ex) {
            throw new WebApplicationException(ex);
        }
    }
```&lt;/p&gt;
&lt;p&gt;### PoC
1. Create a **new** Keycloak realm other than `master`. Add a user and grant that user the OpenRemote client role `write:admin`. Remember the realm name (call it `NEW_REALM`).
2. I…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: io.openremote:openremote-manager&lt;/p&gt;
&lt;p&gt;### Summary
A user who has `write:admin` in one Keycloak realm can call the Manager API to update **Keycloak realm roles** for users in **another** realm, including **`master`**. The handler uses the `{realm}` path segment when talking to the identity provider but does not check that the caller may administer that realm. This could result in a privilege escalation to `master` realm administrator if the attacker controls any user in `master` realm.&lt;/p&gt;
&lt;p&gt;### Details
In `manager/src/main/java/org/openremote/manager/security/UserResourceImpl.java`, there is no check to validate if the caller should be able to administer a realm they&amp;#39;re trying to update.&lt;/p&gt;
&lt;p&gt;```340:353:manager/src/main/java/org/openremote/manager/security/UserResourceImpl.java
    @Override
    public void updateUserRealmRoles(RequestParams requestParams, String realm, String userId, String[] roles) {
        try {
            identityService.getIdentityProvider().updateUserRealmRoles(
                realm,
                userId,
                roles);
        } catch (ClientErrorException ex) {
            ex.printStackTrace(System.out);
            throw new WebApplicationException(ex.getCause(), ex.getResponse().getStatus());
        } catch (Exception ex) {
            throw new WebApplicationException(ex);
        }
    }
```&lt;/p&gt;
&lt;p&gt;### PoC
1. Create a **new** Keycloak realm other than `master`. Add a user and grant that user the OpenRemote client role `write:admin`. Remember the realm name (call it `NEW_REALM`).
2. I…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-49vv-25qx-mg44</guid>
    </item>
  </channel>
</rss>
