Io.openremote:openremote manager: OpenRemote Manager: removeAlarms cross-realm IDOR (bulk delete) (CVE-2026-57168)
### Summary 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 (!isRealmActiveAndAccessible(alarm.getRealm())) { throw new ForbiddenException(...); } The plural removeAlarms() method is missing this per-alarm realm check and only validates the caller's own realm — a check that is trivially satisfied for any authenticated user: ``` // VULNERABLE (plural): public void removeAlarms(RequestParams requestParams, List<Long> alarmIds) { if (!isRealmActiveAndAccessible(getAuthenticatedRealmName())) { throw new ForbiddenException(...); // always passes for any auth user } List<SentAlarm> alarms = alarmService.getAlarms(alarmIds); // no realm filter alarmService.removeAlarms(alarms, alarmIds); // no realm filter } ``` The underlying service queries contain no realm scoping: ``` // AlarmService.getAlarms(List<Long>): "select sa from SentAlarm sa where sa.id in :ids" // no realm filter // AlarmService.removeAlarms(): "delete from SentAlarm sa where sa.id in :ids" // no realm filter ``` Alarm IDs are sequential auto-increment Long values (JPA @GeneratedValue), making them trivially enumerable. [Vulnerability Type] Insecure Direct Object Reference (IDOR) / Missing Authorization CWE-639: Authorization Bypass Through User-Controlled Key CWE-862: Missing Authorization ------------------------------------------ [Vendor of Product] OpenRemote Inc. (openremote.io) ------------------------------------------ [Affected Product Code Base] OpenRemote Manager - current version as of 2026 (github.com/openremote/openremote) ------------------------------------------ [Affected Component] org.openremote.manager.alarm.AlarmResourceImpl#removeAlarms() org.openremote.manager.alarm.AlarmService#getAlarms(List<Long>) org.openremote.manager.alarm.AlarmService#removeAlarms() File: manager/src/main/java/org/openremote/manager/alarm/AlarmResourceImpl.java File: manager/src/main/java/org/openremote/manager/alarm/AlarmService.java ------------------------------------------ [Attack Type] Remote (authenticated) ------------------------------------------ [CVE Impact Other] Cross-tenant permanent destruction of alarm records, including safety-critical and security alerts in IoT environments. Also enables cross-tenant alarm enumeration (presence disclosure of alarm IDs across all tenants). ------------------------------------------ [Attack Vectors] 1. Attacker registers or obtains any low-privilege account in any realm on the target OpenRemote installation (or uses an existing account). 2. Attacker enumerates alarm IDs belonging to other realms by sending bulk delete requests with sequential IDs (presence confirmed by 404 vs 200 response codes). 3. Attacker issues a single bulk delete request containing IDs of alarms belonging to victim realm(s). 4. Alarms are permanently deleted with no authorization error. PoC: ``` Tenant A (attacker) : realm = "tenant-a" user = [email protected] role = WRITE_ALARMS_ROLE Tenant B (victim) : realm = "tenant-b" alarms with IDs 1174,1173, 1180 exist ``` ``` DELETE /api/smartcity/alarm HTTP/2 Content-Type: application/json [1174,1173, 1180] /// <- alarm ID ``` <img width="1280" height="404" alt="image" src="https://github.com/user-attachments/assets/ffbebea2-2248-42a0-bb22-7a0dc51c78ce" />
AI Analysis
Technical Summary
The vulnerability in OpenRemote Manager arises from missing authorization checks in the bulk removeAlarms() method, which fails to verify that each alarm ID belongs to the caller's realm before deletion. While the singular removeAlarm() method enforces realm validation, the bulk method only confirms the caller's realm is active, then deletes alarms by IDs without filtering by realm. This allows any authenticated user with alarm write permissions in their own realm to enumerate and delete alarms belonging to other tenants, resulting in cross-tenant permanent destruction of alarm records, including safety-critical and security alerts. The affected component is org.openremote.manager.alarm.AlarmResourceImpl#removeAlarms() and related AlarmService methods. The attack requires authentication and leverages sequential alarm IDs for enumeration and deletion.
Potential Impact
An attacker with any authenticated account and alarm write permissions in their own realm can permanently delete alarms belonging to other tenants on the same OpenRemote installation. This includes safety-critical and security alerts, potentially disrupting monitoring and response in IoT environments. The vulnerability also allows cross-tenant enumeration of alarm IDs, disclosing presence information across tenants. The impact is a complete loss of integrity and availability of alarm data across tenant boundaries.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until a fix is available, restrict alarm write permissions to trusted users only and monitor for suspicious bulk alarm deletion requests. Avoid using the bulk removeAlarms() API with untrusted input. The vendor has not provided an official fix or patch link as of the published date.
Io.openremote:openremote manager: OpenRemote Manager: removeAlarms cross-realm IDOR (bulk delete) (CVE-2026-57168)
Description
### Summary 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 (!isRealmActiveAndAccessible(alarm.getRealm())) { throw new ForbiddenException(...); } The plural removeAlarms() method is missing this per-alarm realm check and only validates the caller's own realm — a check that is trivially satisfied for any authenticated user: ``` // VULNERABLE (plural): public void removeAlarms(RequestParams requestParams, List<Long> alarmIds) { if (!isRealmActiveAndAccessible(getAuthenticatedRealmName())) { throw new ForbiddenException(...); // always passes for any auth user } List<SentAlarm> alarms = alarmService.getAlarms(alarmIds); // no realm filter alarmService.removeAlarms(alarms, alarmIds); // no realm filter } ``` The underlying service queries contain no realm scoping: ``` // AlarmService.getAlarms(List<Long>): "select sa from SentAlarm sa where sa.id in :ids" // no realm filter // AlarmService.removeAlarms(): "delete from SentAlarm sa where sa.id in :ids" // no realm filter ``` Alarm IDs are sequential auto-increment Long values (JPA @GeneratedValue), making them trivially enumerable. [Vulnerability Type] Insecure Direct Object Reference (IDOR) / Missing Authorization CWE-639: Authorization Bypass Through User-Controlled Key CWE-862: Missing Authorization ------------------------------------------ [Vendor of Product] OpenRemote Inc. (openremote.io) ------------------------------------------ [Affected Product Code Base] OpenRemote Manager - current version as of 2026 (github.com/openremote/openremote) ------------------------------------------ [Affected Component] org.openremote.manager.alarm.AlarmResourceImpl#removeAlarms() org.openremote.manager.alarm.AlarmService#getAlarms(List<Long>) org.openremote.manager.alarm.AlarmService#removeAlarms() File: manager/src/main/java/org/openremote/manager/alarm/AlarmResourceImpl.java File: manager/src/main/java/org/openremote/manager/alarm/AlarmService.java ------------------------------------------ [Attack Type] Remote (authenticated) ------------------------------------------ [CVE Impact Other] Cross-tenant permanent destruction of alarm records, including safety-critical and security alerts in IoT environments. Also enables cross-tenant alarm enumeration (presence disclosure of alarm IDs across all tenants). ------------------------------------------ [Attack Vectors] 1. Attacker registers or obtains any low-privilege account in any realm on the target OpenRemote installation (or uses an existing account). 2. Attacker enumerates alarm IDs belonging to other realms by sending bulk delete requests with sequential IDs (presence confirmed by 404 vs 200 response codes). 3. Attacker issues a single bulk delete request containing IDs of alarms belonging to victim realm(s). 4. Alarms are permanently deleted with no authorization error. PoC: ``` Tenant A (attacker) : realm = "tenant-a" user = [email protected] role = WRITE_ALARMS_ROLE Tenant B (victim) : realm = "tenant-b" alarms with IDs 1174,1173, 1180 exist ``` ``` DELETE /api/smartcity/alarm HTTP/2 Content-Type: application/json [1174,1173, 1180] /// <- alarm ID ``` <img width="1280" height="404" alt="image" src="https://github.com/user-attachments/assets/ffbebea2-2248-42a0-bb22-7a0dc51c78ce" />
CVSS v3.1
Score 9.6critical
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability in OpenRemote Manager arises from missing authorization checks in the bulk removeAlarms() method, which fails to verify that each alarm ID belongs to the caller's realm before deletion. While the singular removeAlarm() method enforces realm validation, the bulk method only confirms the caller's realm is active, then deletes alarms by IDs without filtering by realm. This allows any authenticated user with alarm write permissions in their own realm to enumerate and delete alarms belonging to other tenants, resulting in cross-tenant permanent destruction of alarm records, including safety-critical and security alerts. The affected component is org.openremote.manager.alarm.AlarmResourceImpl#removeAlarms() and related AlarmService methods. The attack requires authentication and leverages sequential alarm IDs for enumeration and deletion.
Potential Impact
An attacker with any authenticated account and alarm write permissions in their own realm can permanently delete alarms belonging to other tenants on the same OpenRemote installation. This includes safety-critical and security alerts, potentially disrupting monitoring and response in IoT environments. The vulnerability also allows cross-tenant enumeration of alarm IDs, disclosing presence information across tenants. The impact is a complete loss of integrity and availability of alarm data across tenant boundaries.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until a fix is available, restrict alarm write permissions to trusted users only and monitor for suspicious bulk alarm deletion requests. Avoid using the bulk removeAlarms() API with untrusted input. The vendor has not provided an official fix or patch link as of the published date.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-h3m5-97jq-qjrf
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-57168"]
- Ecosystems
- ["Maven"]
- Database Specific Severity
- CRITICAL
- Cvss Version
- 3.1
Threat ID: 6a46ecb527e9c7971943c8b3
Added to database: 07/02/2026, 22:56:53 UTC
Last enriched: 07/02/2026, 23:09:55 UTC
Last updated: 07/31/2026, 19:40:06 UTC
Views: 53
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.