CVE-2026-89054: OpenNMS missing authorization on /api/v2 PATCH endpoints allows unauthenticated configuration changes
A missing authorization vulnerability in OpenNMS Horizon allows configuration changes without authentication. The Spring Security policy for the /api/v2 REST API defines authorization rules for every HTTP method except PATCH, so the shipped @PATCH configuration endpoints for event configuration and SNMP data collection (which enable and disable event definitions and data-collection sources) are reachable with no authorization enforced. An unauthenticated attacker able to reach the web UI can disable event definitions and SNMP data collection, suppressing event and alarm generation and stopping metric collection - silently degrading monitoring and detection - with the change persisted and reloaded into the running system.
The solution is to upgrade to Horizon 36.0.4 or newer. Meridian and Horizon installation instructions state that they are intended for installation within an organization's private networks and should not be directly accessible from the Internet.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
OpenNMS Horizonto a version that resolves this vulnerability.Fixed in 36.0.4
Event History
Frequently Asked Questions
Who can exploit this issue?
Any unauthenticated attacker who can reach the OpenNMS web UI can exploit the affected PATCH endpoints. No credentials or user interaction are required.
Are default deployments exposed to the vulnerable endpoints?
The vulnerable authorization policy is part of the shipped /api/v2 REST API configuration, and the affected event-configuration and SNMP data-collection PATCH endpoints are shipped endpoints. Exposure depends on whether an attacker can reach the web UI; installation guidance says OpenNMS should be deployed only on private networks and not directly exposed to the Internet.
What can an attacker change, and what is the operational impact?
An attacker can enable or disable event definitions and SNMP data-collection sources. This can suppress event and alarm generation and halt metric collection, silently degrading monitoring and detection; the changes persist and are reloaded by the running system.
What should teams do if they cannot upgrade immediately?
Restrict access to the OpenNMS web UI so unauthenticated or untrusted users cannot reach it, particularly from the Internet. The documented remediation is upgrading Horizon to version 36.0.4 or newer.
How can administrators identify potential compromise?
Review event-definition and SNMP data-collection source configuration for unexpected enablement or disablement, and investigate unexplained gaps in events, alarms, or metric collection. The affected changes are persisted in configuration and reloaded into the running system.