Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The datapoint export API builds a PostgreSQL crosstab export query by concatenating asset display names into raw SQL. An authenticated user who can create or rename an asset and then request a crosstab datapoint export can inject SQL through the asset name. The injected query output is streamed back to the caller inside the normal ZIP/CSV export response. This creates a practical database exfiltration primitive through the application API. In a multi-tenant deployment, this can expose data outside the attacker's tenant if the application database role can read shared manager tables. Affected Component - Datapoint export endpoint for asset datapoints. - Crosstab export formats, specifically CSV crosstab-style exports. - Query builder path that constructs a `COPY (SELECT ... FROM crosstab(...)) TO STDOUT` statement. Security Impact Impact is high. A remote authenticated attacker with asset read/write capabilities can: - Store SQL syntax inside an asset name. - Trigger…
Recommended action: Upgrade to 1.26.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.READADMIN.getValue(), Constants.KEYCLOAKCLIENTID); if (!hasAdminReadRole && !Objects.equals(getUserId(), userId)) {…
Recommended action: Upgrade to 1.24.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The predicted datapoint write endpoint allows users with only read:assets privileges to write predicted datapoints. The endpoint: accepts write requests from users lacking write:assets. The implementation appears to check READASSETS while performing a write operation through: PoC A user was created with only: and without write:assets. The following request succeeded: Request body: Response: Database verification confirmed the datapoint was written successfully: Impact Users with read-only asset permissions can modify predicted datapoints for assets.
Recommended action: Upgrade to 1.24.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenRemote Manager is vulnerable to a cross-tenant Insecure Direct Object Reference (IDOR) in the bulk alarm deletion endpoint. An authenticated user in any realm can delete alarms belonging to other realms (tenants) by supplying arbitrary alarm IDs. The vulnerability exists because the bulk removeAlarms() method only verifies that the caller's own realm is active and accessible, but never checks whether the targeted alarm IDs belong to the caller's realm before deleting them. This allows any user with alarm write permissions in their own realm to permanently destroy alarm records — including safety-critical and security alerts — belonging to any other tenant on the same OpenRemote installation. ------------------------------------------ [Additional Information] The singular removeAlarm() method correctly validates that the target alarm's realm matches the caller's access: // CORRECT (singular): SentAlarm alarm = alarmService.getAlarm(alarmId); if…
Recommended action: Upgrade to 1.25.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. 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 NEWREALM). 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…
Recommended action: Upgrade to 1.22.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Velbus asset import path parses attacker-controlled XML without explicit XXE hardening. An authenticated user who can call the import endpoint may trigger XML external entity processing, which can lead to server-side file disclosure and SSRF. The target file must be less than 1023 characters. Details Velbus import uses DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(...) on untrusted XML input, without explicit safeguards to disable DTD/external entities. Expanded Caption content is propagated into created asset names: PoC 1. Log in to a realm with a user that can call Velbus asset import. 2. Create/select a Velbus TCP Agent in that same realm. 3. Send POST /api/{realm}/agent/assetImport/{agentId} with a Velbus project XML payload and compare behavior against a baseline import file. 3. Save the below code as a xxe.xml and upload to Setup under https://localhost/manager/?realm=<YOURREALM#/assets/false/<ASSETID. Chnage the file:///etc/passwd to another file…
Recommended action: Upgrade to 1.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The OpenRemote IoT platform's rules engine contains two interrelated critical expression injection vulnerabilities that allow an attacker to execute arbitrary code on the server, ultimately achieving full server compromise. - Unsandboxed Nashorn JavaScript Engine: JavaScript rules are executed via Nashorn's ScriptEngine.eval() with user-supplied script content and no sandboxing, class filtering, or access restrictions. Critically, any non-superuser with the write:rules role can create JavaScript rulesets. - Inactive Groovy Sandbox: The Groovy rules engine has a GroovyDenyAllFilter security filter that is defined but never registered (the registration code is commented out), rendering the SandboxTransformer ineffective. While Groovy rules are restricted to superusers, the absence of sandboxing violates the principle of defense in depth. Details Attacker-Controllable Source-to-Sink Paths There are two non-superuser and two superuser exploitable attack paths from the REST API…
Recommended action: Upgrade to 1.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.