GHSA-H3M5-97JQ-QJRF: Insecure Direct Object Reference (IDOR) Cross-Realm Bulk Alarm Deletion in OpenRemote Manager

OpenRemote Manager is an open-source Internet of Things (IoT) device management platform. It relies on a multi-tenant architecture designed to partition operational assets, users, and telemetry into logical units called realms. The system implements strict access controls to prevent users of one realm from reading, writing, or deleting resources in another realm.

This vulnerability, tracked under GHSA-H3M5-97JQ-QJRF, lies in the API endpoint designated for bulk alarm deletion. The removeAlarms method fails to validate whether the database identifiers supplied in the HTTP request belong to the tenant realm of the authenticated caller. Consequently, a low-privilege attacker can exploit this missing authorization check to execute a cross-realm Insecure Direct Object Reference (IDOR) attack.

The structural flaw allows an authenticated tenant user to systematically purge security and safety-critical alarms across the entire platform. The impact directly degrades the integrity and availability of operational telemetry. This technical report provides a comprehensive analysis of the code-level flaw, exploitation techniques, and remediation strategies.

The root cause of this vulnerability resides within the implementation of the bulk deletion endpoint in AlarmResourceImpl.java. In multi-tenant systems, security boundaries must be enforced at every data-access layer. The individual alarm deletion endpoint (removeAlarm) successfully limits operations to the caller's realm, but the bulk variant (removeAlarms) fails to replicate these security controls.

Specifically, the endpoint extracts the caller's authenticated realm and validates its state via isRealmActiveAndAccessible(). However, this function only checks if the caller's own realm is active. Because the attacker is a valid user within an active realm, this conditional check always evaluates to true, authorizing the initiation of the deletion sequence.

Once authorized globally, the application queries the persistent store using the service method alarmService.getAlarms(alarmIds). This query retrieves the database objects using raw, unscoped Hibernate/JPA queries. Because the underlying relational database uses auto-incrementing Long integers for alarm entities, an attacker can easily predict and reference target records from other realms.

The persistence layer subsequently processes the list of retrieved objects and executes a bulk delete transaction. Since the query is not constrained by a realm-based WHERE clause, the application purges the specified records regardless of their owner. The absence of an iterative ownership validation loop allows the deletion to cross tenant boundaries unchecked.

The flaw is localized within org.openremote.manager.alarm.AlarmResourceImpl.java and org.openremote.manager.alarm.AlarmService.java. In the vulnerable implementation, the application first performs a generic realm validation and immediately proceeds to database operations.

// Vulnerable Code Path
public void removeAlarms(RequestParams requestParams, List<Long> alarmIds) {
    try {
        // Generic check verifies ONLY the attacker's realm, which is always active
        if (!isRealmActiveAndAccessible(getAuthenticatedRealmName())) {
            throw new ForbiddenException("Realm '" + getAuthenticatedRealmName() + "' is inaccessible");
        }
        // Unscoped load from the database across all tenant boundaries
        List<SentAlarm> alarms = alarmService.getAlarms(alarmIds);
        // Executes the cross-realm bulk deletion
        alarmService.removeAlarms(alarms, alarmIds);
    } catch (EntityNotFoundException e) {
        throw new WebApplicationException(Response.Status.NOT_FOUND);
    }
}

The patch resolved this by executing the database query first and iterating over the retrieved SentAlarm records. By reading the associated realm property of each loaded alarm, the application can verify if the user possesses authorization for every specific asset.

// Patched Code Path
public void removeAlarms(RequestParams requestParams, List<Long> alarmIds) {
    try {
        // First retrieve the list of target alarms
        List<SentAlarm> alarms = alarmService.getAlarms(alarmIds);
        // Iterate and validate the realm of each target alarm
        for (SentAlarm alarm : alarms) {
            if (!isRealmActiveAndAccessible(alarm.getRealm())) {
                throw new ForbiddenException("Realm '" + alarm.getRealm() + "' is inaccessible");
            }
        }
        // Only execute deletion if all elements pass the authorization check
        alarmService.removeAlarms(alarms, alarmIds);
    } catch (EntityNotFoundException e) {
        throw new WebApplicationException(Response.Status.NOT_FOUND);
    }
}

While the patch effectively remediates the authorization bypass, it introduces a memory overhead consideration. An attacker can supply a massive array of valid integers to force the application to load thousands of records into the JVM heap. This behavior can lead to heap exhaustion or connection pool depletion, making request payload size limits an essential secondary defense.

Exploitation of GHSA-H3M5-97JQ-QJRF requires network access to the OpenRemote Manager API and a valid set of credentials for any active realm. The attacker does not need administrative privileges or access to the target realm. A low-privilege tenant account suffices to generate the necessary authorization tokens.

The attack begins with authentication against the OpenRemote instance to acquire a JSON Web Token (JWT) or session cookie. Because alarm identifiers are sequential auto-incrementing integers, the attacker can guess valid target keys. An attacker can perform ID enumeration by observing response patterns: valid IDs return 204 No Content or 200 OK, whereas missing IDs throw 404 Not Found errors.

Once the target identifiers are established, the attacker sends a crafted DELETE request to the bulk alarm endpoint. The request payload contains an array of the targeted integer IDs. The application processes the array, retrieves the alarms, and deletes them across tenant boundaries.

DELETE /api/smartcity/alarm HTTP/2
Host: openremote.example.com
Authorization: Bearer <tenant-a-attacker-token>
Content-Type: application/json
 
[1174, 1173, 1180]

Following the processing of this request, the database records representing the alarms are deleted permanently. The target tenant (Tenant B) loses all historical and active alarm states without any warning, alerts, or audit trails indicating an unauthorized action.

The vulnerability represents a severe threat to the operational integrity of systems managed via OpenRemote. Alarms in OpenRemote are critical for monitoring industrial, municipal, and enterprise IoT infrastructures. The unauthorized deletion of these records directly disrupts automated response mechanisms and human operator oversight.

The CVSS v3.1 base score of 9.6 reflects the critical nature of this vulnerability. The high integrity and availability impact parameters indicate that safety-critical infrastructure could be left unmonitored. While confidentiality is marked as none because the endpoint does not return alarm payloads, information leakage still occurs via ID enumeration.

The Scope (S) parameter is marked as Changed (C) because the exploit breaks the fundamental isolation boundary of the multi-tenant application. An attack originating from a restricted, low-privilege client account propagates into separate tenant spaces. This behavior undermines the security guarantees of the SaaS platform.

The primary and recommended mitigation is to upgrade the OpenRemote Manager package to version 1.24.2 or later. This release integrates the necessary iterative checks to validate that the caller's realm matches the resource realm. Upgrading requires rebuilding the OpenRemote deployment with the updated Maven dependency.

In environments where immediate upgrading is not feasible, organizations should implement Web Application Firewall (WAF) rules to inspect and restrict bulk DELETE operations. WAF rules should block requests to the alarm endpoints containing excessively large JSON arrays. Limiting the payload size reduces the capability of an attacker to execute wide-scale automated sweeping attacks.

Additionally, security teams should configure strict API rate limiting on the /api/[realm]/alarm endpoints to impede automated ID enumeration. Monitoring server access logs for anomalous DELETE requests originating from non-administrative accounts is also advised. Rapid successions of bulk deletion actions can indicate ongoing reconnaissance or active exploitation phases.