OpenNMS EUVD-2026-75725

Exploitation requires that: (1) the OpenNMS XML collector is configured and actively polling one or more HTTP or network-accessible XML data sources; and (2) the attacker either controls the response from one of those monitored endpoints (via host compromise) or occupies a network MitM position on the path between OpenNMS and the target URL. No authentication to OpenNMS itself is required. The vulnerability is limited to deployments where the XML collector feature is in use - installations that collect data only via SNMP, JMX, or other non-XML collectors are not exposed. Because OpenNMS is designed for internal-network deployment, the MitM prerequisite limits the realistic attacker pool to insiders or attackers already present on the monitoring VLAN. Out-of-band exfiltration further requires that the OpenNMS host can initiate outbound DNS or HTTP connections to attacker-controlled infrastructure.

The CVSS 3.1 score of 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N) is well-calibrated: the network vector reflects that OpenNMS contacts remote monitored hosts over HTTP, but AC:H correctly captures the non-trivial precondition of attaining a MitM position or compromising a monitored endpoint. Confidentiality impact is genuinely high - the OpenNMS service account typically has read access to configuration files containing database credentials, which are the primary exfiltration target. Integrity and availability are unaffected by the XXE vector itself. No EPSS data was provided and no CISA KEV listing is present, which together with the AC:H prerequisite suggests this is not under active mass exploitation. However, the confidentiality consequence (credential theft leading to database compromise) means that even a mid-sized municipal IT team in malbork using OpenNMS for infrastructure monitoring should treat patching as urgent rather than routine. OpenNMS's own documentation notes the product is intended for deployment within private networks only, which substantially limits internet-facing exposure but does not eliminate the insider-threat or compromised-node scenario.

An attacker who has compromised a server that OpenNMS monitors via the XML collector (or who holds a network MitM position on the path to an HTTP-based XML data source) modifies the response to include a malicious DOCTYPE declaration referencing an external entity pointing to a local file such as /opt/opennms/etc/opennms-datasources.xml. When OpenNMS's XML collector fetches and parses the response, the unpatched parser resolves the entity and the file contents are transmitted out-of-band to an attacker-controlled DNS or HTTP server, yielding database credentials.