OpenNMS Horizon CVE-2026-19182

Exploitation requires a valid authenticated account with the ROLE_REST role explicitly assigned within OpenNMS; this role is a deliberate administrator grant, not a default for newly created users. The ROLE_READONLY bypass variant additionally requires the attacker account to hold both ROLE_REST and ROLE_READONLY simultaneously. The REST API endpoint must be network-reachable from the attacker's position. Limiting factors include the mandatory ROLE_REST authentication requirement (CVSS PR:L confirms this), the fact that OpenNMS is architecturally intended for private-network deployment limiting internet exposure, and that exploitation affects only alarm state integrity - it yields no code execution, no credential disclosure, and no system-level access. No special non-default product configuration is required beyond having any ROLE_REST account in the system; the flaw exists in all standard deployments running a vulnerable version.

The CVSS 3.1 score of 4.3 (Medium) accurately reflects the bounded impact: network-reachable and low-complexity, but gated behind a ROLE_REST credential and producing only low-integrity impact with no confidentiality or availability effect. No EPSS data was provided, the vulnerability is absent from CISA KEV, and no public exploit code has been identified at time of analysis. Real-world risk is further bounded by the vendor's documented deployment posture - OpenNMS is explicitly intended for installation within private organizational networks, so internet-facing exposure should be exceptional rather than typical. That said, even a mid-sized municipal IT operations team in bytom relying on OpenNMS for infrastructure visibility faces meaningful risk if a rogue or compromised ROLE_REST account is used to attribute alarm acknowledgements to innocent staff, corrupting audit trails and potentially obscuring active incidents. The ROLE_READONLY bypass is particularly notable because it violates an explicit, named security boundary that administrators may have deliberately configured. Overall priority is moderate for organizations with broad ROLE_REST grants, and low for those with tightly controlled accounts and proper network segmentation.

An insider or attacker who has obtained a valid ROLE_REST account sends an HTTP PUT request to /api/v2/alarms/{id} with the query parameter ackUser=<victim_username>, where the victim is any valid system account. Because the inverted condition never fires for a non-blank string, the system records the alarm acknowledgement as the victim user without any delegation check. No publicly available exploit code is required - the attack is a trivial API call with a modified parameter, executable with any standard HTTP client.