CVE-2026-56784: OpenRemote IDOR Allows Cross-Tenant Alarm Deletion

Technical summary

CVE-2026-56784 is an Insecure Direct Object Reference (IDOR) vulnerability affecting OpenRemote's alarm management REST API. The removeAlarms() method in AlarmResourceImpl.java constructs JPA queries without realm-scoping filters, meaning the authorization check only verifies that the user has write permissions to *some* alarm resource, not whether they own the specific alarm being deleted. An attacker can iterate through sequential auto-increment alarm IDs and delete records across tenant boundaries. The vulnerability requires prior authentication and basic alarm-write role assignment, but imposes no additional constraints on which alarm IDs can be targeted.

Business impact

Organizations relying on OpenRemote's multi-tenant alarm infrastructure may experience loss of critical operational alerts without audit trail visibility into unauthorized deletions. This affects IoT and building automation deployments where alarms trigger maintenance workflows, security responses, or compliance notifications. Malicious insiders or compromised accounts with low-privilege roles can sabotage monitoring across unrelated customer instances, undermining operational continuity and potentially delaying incident response.

Affected systems

OpenRemote versions prior to 1.25.0 are affected. The vendor_products field in the advisory data is empty, so verify against the official OpenRemote security advisory to confirm the complete list of impacted versions and any downstream products that embed this platform.

Exploitability

Exploitation requires an authenticated account with alarm-write permissions—a common role in multi-tenant SaaS deployments. No user interaction, complex exploitation steps, or specialized tools are needed beyond standard HTTP requests. The sequential auto-increment ID structure makes enumeration trivial. However, the attacker must have valid credentials to the target OpenRemote instance; unauthenticated exploitation is not possible.

Remediation

Upgrade to OpenRemote 1.25.0 or later, which restores realm-scoping validation to the removeAlarms() JPA query. Verify the patch changelog confirms that tenant isolation filters are now applied to bulk deletion operations. Until patching is feasible, restrict alarm-write role assignments to trusted administrators and implement network segmentation to limit authenticated access to the alarm management API.

Patch guidance

Consult the official OpenRemote release notes for version 1.25.0 and later to confirm patch availability and any deployment prerequisites. Test the upgrade in a non-production environment to validate compatibility with your alarm schema and integrated monitoring systems. Document the patch date for audit purposes, as the modified date of 2026-07-14 may indicate post-release refinements to the fix.

Detection guidance

Monitor API logs for repeated DELETE requests to the bulk alarm endpoint with varying alarm IDs, especially across different tenant contexts if multi-tenancy is logged. Look for alarm deletion events that do not correlate with administrative change requests. Review access logs for users with alarm-write permissions accessing alarms outside their assigned scope. If supported, enable audit logging at the JPA layer to capture object-level access patterns in the alarm table.

Why prioritize this

The CVSS 3.1 score of 8.1 (HIGH) reflects high confidentiality and integrity impact within a single-tenant context; however, the multi-tenant isolation breach elevates business risk. Prioritize patching in environments where alarm loss could cascade into undetected outages or compliance violations. Organizations with strict data isolation requirements should treat this as critical despite the CVSS rating.

Risk score, explained

The score of 8.1 is driven by high integrity impact (permanent, unauthorized data deletion) and high confidentiality impact (enumeration of tenant alarm structures). The attack vector is network-based and complexity is low. The requirement for authentication (PR:L) and lack of scope change prevent a critical rating. Scope remains unchanged because the vulnerability affects the same service boundary, not system-wide privileges.

Frequently asked questions