A denial of service vulnerability exists in the XML parsing of multiple versions of OpenNMS Meridian and Horizon. OpenNMS parsed XML without an effective limit on entity expansion. A document with a DOCTYPE that declares internal entities can expand to a very large value and exhaust the server memory. An authenticated user with provisioning access can supply such a document through a requisition or foreign-source import, which includes a remote requisition URL that the server fetches and parses. Both deeply nested entities and a single large entity referenced many times cause the memory exhaustion. The fix caps the number of entity expansions for all XML parsing and rejects any DOCTYPE in requisition and foreign-source XML.

The solution is to upgrade to Meridian 2024.3.14, 2025.0.11, 2026.0.1 and Horizon 36.0.5 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.

An authorization bypass vulnerability exists in the REST API of multiple versions of OpenNMS Meridian and Horizon. The /rest/ Spring Security filter chains authorize requests with intercept-url rules that name the HTTP method as an uppercase token, compare the method case-sensitively, and have no terminal deny rule. A request that uses a non-canonical (for example lowercase) method token matches no rule and is processed without authentication. A remote, unauthenticated attacker can read the monitored inventory and can create, modify, or delete resources through the REST API, which includes injecting events to fabricate or suppress alarms. The /rest/alarms chain has the same missing deny rule and discloses whether an alarm exists through a difference in the response. The fix adds a terminal deny rule to each REST filter chain.

The solution is to upgrade to Meridian 2024.3.14, 2025.0.11, 2026.0.1 and Horizon 36.0.5 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.

An incorrect authorization check in the v2 Alarm REST API in OpenNMS Meridian and Horizon allows a low-privileged authenticated user (ROLEREST) to acknowledge, escalate, or clear alarms recorded as an arbitrary username, and, when also assigned ROLEREADONLY, to modify alarm state despite the read-only restriction. A credential check that should restrict these operations is guarded by an inverted condition, so it never executes for a real (non-blank) username. This can potentially allow an attacker to compromise the integrity of alarm state and audit records.

The solution is to upgrade to Meridian 2024.3.12, 2025.0.9 and Horizon 36.0.3 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.

OpenNMS Meridian 2016, 2017, 2018 before 2018.1.25, 2019 before 2019.1.16, and 2020 before 2020.1.5, Horizon 1.2 through 27.0.4, and Newts <1.5.3 has Incorrect Access Control, which allows local and remote code execution using JEXL expressions.

OpenNMS has a default password of rtc for the rtc account, which makes it easier for remote attackers to obtain access by leveraging knowledge of the credentials.

OpenNMS version 18.0.1 and prior are vulnerable to a stored XSS issue due to insufficient filtering of SNMP trap supplied data. By creating a malicious SNMP trap, an attacker can store an XSS payload which will trigger when a user of the web UI views the events list page. This issue was fixed in version 18.0.2, released on September 20, 2016.

OpenNMS is accessible via port 9443

OpenNMS version 18.0.1 and prior are vulnerable to a stored XSS issue due to insufficient filtering of SNMP agent supplied data. By creating a malicious SNMP 'sysName' or 'sysContact' response, an attacker can store an XSS payload which will trigger when a user of the web UI views the data. This issue was fixed in version 18.0.2, released on September 20, 2016.

Multiple cross-site scripting (XSS) vulnerabilities in OpenNMS before 1.5.94 allow remote attackers to inject arbitrary web script or HTML via (1) the jusername parameter to jacegisecuritycheck, (2) the username parameter to notification/list.jsp, and (3) the filter parameter to event/list.

An issue was discovered in OpenNMS Horizon before 26.0.1, and Meridian before 2018.1.19 and 2019 before 2019.1.7. The ActiveMQ channel configuration allowed for arbitrary deserialization of Java objects (aka ActiveMQ Minion payload deserialization), leading to remote code execution for any authenticated channel user regardless of its assigned permissions.

In OpenNMS Horizon, versions opennms-1-0-stable through opennms-27.1.0-1; OpenNMS Meridian, versions meridian-foundation-2015.1.0-1 through meridian-foundation-2019.1.18-1; meridian-foundation-2020.1.0-1 through meridian-foundation-2020.1.6-1 are vulnerable to Stored Cross-Site Scripting, since the function validateFormInput() performs improper validation checks on the input sent to the userID parameter. Due to this flaw an attacker could inject an arbitrary script which will be stored in the database.