OpenRemote Manager CVE-2026-41166

| EUVD-2026-25096 HIGH
Improper Access Control (CWE-284)
2026-04-22 https://github.com/openremote/openremote GHSA-49vv-25qx-mg44
7.0
CVSS 3.1
Share

CVSS VectorNVD

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:L
Attack Vector
Network
Attack Complexity
High
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
High
Availability
Low

Lifecycle Timeline

3
Patch available
Apr 22, 2026 - 22:02 EUVD
Re-analysis Queued
Apr 22, 2026 - 21:22 vuln.today
cvss_changed
Analysis Generated
Apr 22, 2026 - 15:00 vuln.today

DescriptionNVD

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.

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're trying to update.

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);
        }
    }

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. In Keycloak realm master, pick a low-privilege user (no admin realm role). Copy that user’s UUID (<master-user-uuid>).
  3. Authenticate as the user from step 1 and obtain a Bearer access token (<token>) for NEW_REALM.
  4. Replace placeholders and run:
bash
curl -k -X PUT "https://<host>/api/<NEW_REALM>/user/master/userRealmRoles/<master-user-uuid>" \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '["admin"]'
  1. In the Keycloak Admin Console, realm master, that user, Role mapping. Confirm the admin realm role is assigned.

Impact

An attacker with the OpenRemote client role write:admin in any realm can call this API with {realm} set to another realm (for example master) and change Keycloak realm roles for users there. That can grant admin on master to a user UUID they target, which gives Keycloak administrator access for the master realm.

AnalysisAI

OpenRemote Manager allows privilege escalation to Keycloak master realm administrator through improper authorization in the Manager API. Users with write:admin permission in any non-master realm can manipulate realm role assignments in other realms, including master, by exploiting missing authorization checks in the updateUserRealmRoles endpoint. …

Sign in for full analysis, threat intelligence, and remediation guidance.

RemediationAI

Within 24 hours: Identify all OpenRemote Manager deployments and their current versions; confirm Keycloak integration status and affected realm configurations. Within 7 days: Audit user access logs for the updateUserRealmRoles endpoint to detect unauthorized realm role assignment attempts; restrict manager-level permissions in non-master realms to minimum necessary users. …

Sign in for detailed remediation steps.

Share

CVE-2026-41166 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy