CVE-2026-56784: OpenRemote Auth Bypass Vulnerability

CVE-2026-56784 Overview

CVE-2026-56784 is an Insecure Direct Object Reference (IDOR) vulnerability in OpenRemote versions prior to 1.25.0. The flaw resides in the bulk alarm deletion endpoint and allows authenticated users to permanently delete alarms belonging to other tenants. The removeAlarms() method in AlarmResourceImpl.java omits realm-scoping validation in its Java Persistence API (JPA) query. Any user holding alarm-write permissions can enumerate sequential auto-increment alarm IDs and delete cross-tenant alarm records without authorization. The vulnerability is tracked under [CWE-639] (Authorization Bypass Through User-Controlled Key).

Critical Impact
Authenticated low-privilege users can permanently destroy alarm data across all tenants in a shared OpenRemote deployment, breaking multi-tenant isolation and eliminating critical operational alerts.

Affected Products

OpenRemote versions prior to 1.25.0
Multi-tenant OpenRemote deployments exposing the bulk alarm deletion endpoint
Any environment where the AlarmResourceImpl.removeAlarms() method is reachable by authenticated users with alarm-write scope

Discovery Timeline

2026-06-23 - CVE-2026-56784 published to the National Vulnerability Database (NVD)
2026-06-23 - Last updated in NVD database

Technical Details for CVE-2026-56784

Vulnerability Analysis

OpenRemote enforces tenant isolation through a realm model that scopes resources to specific organizations. The bulk alarm deletion handler accepts a list of alarm identifiers from the client and forwards them directly into a JPA delete query. The query does not constrain results to the caller's realm. As a result, the database executes the deletion based solely on the supplied primary keys.

Authenticated attackers can iterate auto-increment integer identifiers to enumerate alarms across every tenant. Because alarm IDs are sequential and predictable, the attacker does not need prior knowledge of valid identifiers. The endpoint completes the operation successfully and removes the records permanently.

The impact is loss of integrity for alarm data across tenants. Operational alerts, audit records, and incident triggers can be erased without leaving the authorized realm. This breaks the cross-tenant trust boundary expected in a shared OpenRemote instance. Refer to the GitHub Security Advisory and the VulnCheck Security Advisory for vendor-provided technical context.

Root Cause

The root cause is missing authorization enforcement in the persistence layer. The removeAlarms() method in AlarmResourceImpl.java constructs a JPA query that filters only on the supplied alarm identifiers. It does not include a realm predicate or verify that each referenced alarm belongs to the caller's tenant. The service trusts client-supplied object references without server-side ownership checks, the defining pattern of [CWE-639].

Attack Vector

Exploitation requires only network access to the OpenRemote API and a valid account with alarm-write permission in any realm. The attacker authenticates, then issues a bulk delete request containing a range of integer alarm IDs harvested through sequential enumeration. The server processes the request and removes every matching record, including those owned by other tenants. No user interaction is required and the attack complexity is low.

No verified proof-of-concept code is publicly available. The vulnerability mechanism is described in the linked vendor advisories.

Detection Methods for CVE-2026-56784

Indicators of Compromise

Bulk alarm deletion requests containing large or sequential ranges of alarm IDs from a single authenticated session
Application logs showing successful deletions where the alarm's owning realm differs from the caller's realm
Unexpected disappearance of alarm records reported by tenant administrators with no corresponding administrative action
HTTP requests to the alarm management endpoint with abnormally large payload arrays of integer identifiers

Detection Strategies

Enable verbose audit logging on the OpenRemote AlarmResource endpoints and correlate the calling realm against the realm of each affected alarm record
Alert on bulk delete operations exceeding a defined threshold of identifiers per request
Implement database-level triggers that log every alarm deletion with the executing principal and the alarm's original realm for post-hoc analysis

Monitoring Recommendations

Monitor authentication logs for accounts performing alarm operations outside their normal usage pattern
Track API request rates against the bulk deletion endpoint and flag enumeration-style sequential ID access
Maintain off-platform backups of alarm metadata to detect tampering and support recovery

How to Mitigate CVE-2026-56784

Immediate Actions Required

Upgrade OpenRemote to version 1.25.0 or later, which adds realm-scoping validation to the removeAlarms() query
Audit existing user accounts and revoke alarm-write permissions that are not strictly required for operations
Review recent alarm deletion activity across all tenants to identify any cross-realm deletions that may have occurred prior to patching
Restore alarm records from backup where unauthorized deletions are confirmed

Patch Information

The vendor fix is available in OpenRemote 1.25.0. The patched removeAlarms() method enforces realm scoping in the JPA query so that deletions are restricted to alarms owned by the caller's tenant. Details are published in the GitHub Security Advisory GHSA-h3m5-97jq-qjrf.

Workarounds

Restrict network access to the OpenRemote API so that only trusted client applications can reach the alarm management endpoints
Reduce the set of users assigned alarm-write roles until the upgrade can be deployed
Place a reverse proxy or web application firewall rule in front of the alarm deletion endpoint to block requests carrying large arrays of sequential identifiers

bash

# Example WAF rule sketch: limit bulk alarm deletion payload size
# Adjust path and threshold to match your deployment
SecRule REQUEST_URI "@beginsWith /api/master/alarm" \
  "id:1056784,phase:2,deny,status:403,\
   chain,msg:'Block oversized bulk alarm delete'"
  SecRule REQUEST_METHOD "@streq DELETE" \
    "chain"
    SecRule REQUEST_BODY_LENGTH "@gt 4096"