EUVD-2026-38444
GHSA-pv42-3qx9-m56g
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network REST endpoint, low complexity; requires any authenticated tenant user (PR:L); scope changes because impact crosses realm boundary; integrity high (bulk deletion), confidentiality low (ID/existence leakage), availability N at system level.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
7Blast Radius
ecosystem impact- 3 maven packages depend on io.openremote:openremote-manager (3 direct, 0 indirect)
Ecosystem-wide dependent count for version 1.25.0.
DescriptionCVE.org
OpenRemote Manager before 1.24.2 contains an insecure direct object reference vulnerability in the removeAlarms() method that allows authenticated users to delete alarms from other tenants by supplying arbitrary alarm IDs. The bulk deletion endpoint fails to validate that targeted alarm IDs belong to the caller's realm, enabling cross-tenant permanent destruction of safety-critical and security alerts.
AnalysisAI
Cross-tenant alarm destruction in OpenRemote Manager before 1.24.2 lets any authenticated user in one realm permanently delete alarms belonging to other tenants by submitting arbitrary alarm IDs to the bulk removeAlarms() endpoint. The flaw is reported by VulnCheck with a CVSS 4.0 score of 8.6 and a proof-of-concept exists per the SSVC assessment, but there is no public exploit identified at time of analysis and the issue is not listed in CISA KEV. Because alarm IDs are sequential auto-increment values, enumeration and mass deletion of safety-critical and security alerts across tenants is trivial.
Technical ContextAI
OpenRemote is an open-source IoT/asset management platform whose Manager component (Maven artifact io.openremote:openremote-manager, CPE cpe:2.3:a:openremote:openremote) enforces multi-tenant isolation via 'realms'. The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key), with an overlapping CWE-862 (Missing Authorization): while the singular removeAlarm() correctly fetches the alarm and checks isRealmActiveAndAccessible(alarm.getRealm()), the bulk removeAlarms() only verifies isRealmActiveAndAccessible(getAuthenticatedRealmName()) - a check trivially satisfied by any logged-in user - and then issues JPA queries ('select sa from SentAlarm sa where sa.id in :ids' / 'delete from SentAlarm sa where sa.id in :ids') with no realm scoping. Combined with sequential @GeneratedValue Long IDs, this turns the endpoint into a cross-realm bulk-delete primitive.
RemediationAI
Vendor-released patch: upgrade OpenRemote Manager to 1.24.2 or later, which adds per-alarm realm validation in the bulk path; consult GHSA-h3m5-97jq-qjrf (https://github.com/openremote/openremote/security/advisories/GHSA-h3m5-97jq-qjrf) and the VulnCheck advisory for details. If immediate upgrade is not possible, restrict access to the bulk alarm deletion REST endpoint at the reverse proxy or API gateway (deny the bulk DELETE path while still allowing the singular removeAlarm() which is correctly scoped) - the trade-off is loss of legitimate bulk-cleanup functionality. As a secondary control, audit existing alarm-write role assignments and remove the privilege from any tenant user that does not strictly need it, and enable database-level audit logging on the SentAlarm table so any cross-realm deletions before patching are detectable; this does not prevent abuse but provides forensic visibility. Avoid relying on alarm ID unpredictability as a control because IDs are sequential auto-increment Longs.
More in Openremote
View allAn issue was discovered in OpenRemote through 1.0.4 allows attackers to execute arbitrary code via a crafted Groovy rule
Unauthorized modification of push notification tokens in OpenRemote before 1.26.2 allows unauthenticated attackers to re
Cross-realm information disclosure in OpenRemote's Notification REST API exposes all tenants' notification history - inc
SQL injection in OpenRemote's datapoint crosstab export endpoint (all versions before 1.26.0) lets an authenticated user
Cross-realm authorization bypass in OpenRemote allows any authenticated realm administrator to permanently delete notifi
Cross-tenant information disclosure in OpenRemote versions before 1.26.2 allows any authenticated user holding the read:
Cross-tenant insecure direct object reference in OpenRemote versions up to and including 1.26.2 allows an authenticated
Same technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today