CVE-2026-57168: 
Java vulnerability analysis and mitigation

CVE-2026-57168 is a cross-tenant Insecure Direct Object Reference (IDOR) vulnerability in OpenRemote Manager's bulk alarm deletion endpoint, allowing authenticated users in any realm to permanently delete alarms belonging to other tenants. It affects all versions of io.openremote:openremote-manager prior to 1.24.2. The vulnerability was discovered and disclosed on June 19, 2026. It carries a CVSS v3.1 base score of 9.6 (Critical) per the GitHub Advisory Database, though the vendor advisory rates it 8.5 (High) (GitHub Advisory, OpenRemote Advisory).

The root cause is a missing per-alarm realm authorization check in AlarmResourceImpl#removeAlarms() (CWE-639: Authorization Bypass Through User-Controlled Key; CWE-862: Missing Authorization). The singular removeAlarm() method correctly fetches the target alarm and validates its realm against the caller's access, but the bulk removeAlarms() method only checks that the caller's own realm is active — a condition trivially satisfied by any authenticated user — before passing the supplied alarm IDs directly to unscoped database queries (select sa from SentAlarm sa where sa.id in :ids and delete from SentAlarm sa where sa.id in :ids). Because alarm IDs are sequential auto-increment Long values (JPA @GeneratedValue), an attacker can trivially enumerate valid IDs across all tenants by observing 404 vs. 200 HTTP response codes on bulk delete requests (GitHub Advisory, AlarmResourceImpl Source, AlarmService Source).

Successful exploitation allows any low-privilege authenticated user in one tenant to permanently and irreversibly delete alarm records belonging to any other tenant on the same OpenRemote installation, including safety-critical and security alerts in IoT environments. Additionally, the enumerable sequential alarm IDs enable cross-tenant alarm presence disclosure, leaking information about alarm activity in other realms. In operational technology (OT) and IoT deployments, destruction of safety alarms could mask ongoing incidents, impair incident response, and create physical safety risks (GitHub Advisory, OpenRemote Advisory).

A proof-of-concept is publicly documented in the security advisory, demonstrating exploitation via a single crafted HTTP DELETE request. No exploit kits or in-the-wild exploitation have been reported as of the disclosure date. The vulnerability requires only a low-privilege authenticated account in any realm on the target installation, making it accessible to any registered user. No EPSS score or CISA KEV catalog entry has been identified for this CVE (OpenRemote Advisory).

1. Obtain access: Register or obtain any low-privilege account with WRITE_ALARMS_ROLE in any realm on the target OpenRemote installation (e.g., attacker@tenant-a.com in realm tenant-a).
2. Authenticate: Log in and obtain a valid session token or bearer token for the attacker's realm.
3. Enumerate cross-tenant alarm IDs: Send bulk DELETE requests to /api/{realm}/alarm with sequential integer lists (e.g., [1, 2, 3, ...]). A 200 response confirms the alarm ID exists (and is deleted); a 404 indicates no alarm with that ID. Use this side-channel to map valid alarm IDs across all tenants.
4. Craft bulk delete payload: Compile a list of alarm IDs belonging to victim tenant(s) (e.g., IDs 1173, 1174, 1180 from tenant-b).
5. Issue cross-tenant delete request: Send the following request authenticated as the attacker:

DELETE /api/smartcity/alarm HTTP/2
Content-Type: application/json

[1174, 1173, 1180]

6. Confirm deletion: The server returns 200 OK and the victim tenant's alarms are permanently deleted with no authorization error (OpenRemote Advisory).

• Network: Repeated HTTP DELETE requests to /api/{realm}/alarm endpoints from a single authenticated session, especially with large or sequential lists of integer alarm IDs; DELETE requests targeting alarm IDs not belonging to the authenticated user's realm.
• Logs: Application access logs showing bulk DELETE requests to the alarm endpoint returning 200 OK for alarm IDs outside the requesting user's realm; patterns of sequential ID probing (many requests with incrementing ID lists, mixing 200 and 404 responses).
• Application Behavior: Unexpected disappearance of alarm records in one tenant coinciding with activity from a user in a different tenant; gaps in alarm ID sequences in the database without corresponding legitimate deletion events in audit logs (OpenRemote Advisory).

Upgrade to OpenRemote Manager version 1.24.2 or later, which is the patched release addressing this vulnerability. The fix adds per-alarm realm validation in the removeAlarms() method, iterating over each fetched alarm and verifying its realm matches the caller's accessible realm before deletion — consistent with the existing logic in the singular removeAlarm() method. No configuration-based workaround is available; upgrading is the only remediation. Organizations should also audit alarm deletion logs for anomalous cross-tenant activity prior to patching (GitHub Advisory, OpenRemote Advisory).