External risk intelligence

OpenNMS REST API Authorization Bypass Vulnerability

CVE advisorySeverity: CRITICAL (CVSS 9.1)

CVE-2026-111235

OpenNMS is a network management platform typically deployed within internal, private network segments to monitor infrastructure. While the vulnerability affects a REST API reachable via network, the product's documentation and intended deployment architecture specify that it should not be directly exposed to the public internet, making public-facing deployments uncommon.

Halo Surface Signal: 2 out of 5 — less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

An authorization bypass in the REST API for OpenNMS management systems could allow unauthorized access and manipulation of monitored inventory and alarms. This vulnerability affects systems that are intended for internal network use, so the primary concern is confirming if any instances are unintentionally exposed.

Unauthenticated access to system management functions.
Confirm if internal-only systems are exposed externally.
Focus on confirming exposure before remediation.

Attack Path

How an attacker could exploit the issue

An attacker can bypass authentication to the OpenNMS REST API by sending requests with non-canonical HTTP method names. This allows them to access and manipulate monitored inventory, create or delete resources, and interfere with alarms.

Unauthenticated network access required.
Non-canonical HTTP method triggers bypass.
Read inventory, modify resources, manipulate alarms.

Live Threat

Current exploitation, exposure, and threat context

When supported by the advisory, an authorization bypass in the REST API could allow an unauthenticated attacker to access sensitive system information, including monitored inventory and alarm status. The attacker could also modify or delete resources, and fabricate or suppress alarms.

Monitored inventory and alarm data at risk.
Unauthenticated network requests could bypass authorization.
Unauthorized data access and configuration changes.

Operational Fix

Recommended remediation, mitigation, and detection steps

This authorization bypass vulnerability in OpenNMS's REST API likely falls under the purview of infrastructure or platform teams, as they typically manage network monitoring tools. The first critical step is for these teams to identify all OpenNMS instances within their environment, confirm their network accessibility, assess business criticality, and then coordinate with the platform or application owner to plan remediation, prioritizing instances with wider exposure or greater impact.

Identify OpenNMS instances and assess exposure.
Confirm owner and business criticality of instances.
Plan remediation based on risk and impact.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is OpenNMS and why is it used?

OpenNMS is an enterprise-grade, open-source network management platform. Organizations use both the Meridian and Horizon versions to monitor the health, availability, and performance of their IT infrastructure. It serves as a central hub for collecting network data, managing devices, and automating alarm responses across complex environments.

What does CVE-2026-111235 mean for the REST API?

This vulnerability is an authorization bypass, specifically categorized as Improper Authorization (CWE-862/863). The API’s security filters expect standard, uppercase HTTP method names. Because the software fails to explicitly block unauthorized requests, an attacker can use non-standard, lowercase method names to bypass the security check, allowing them to interact with the API as if they were an authenticated user.

How does an attacker trigger this bypass?

An attacker triggers the vulnerability by sending a REST API request with a non-canonical HTTP method token, such as a lowercase command. Simply interacting with the API normally using standard uppercase methods will not trigger this flaw. The bypass succeeds because the security filter chain lacks a final 'deny' rule to catch these unusual, non-canonical requests, causing the system to process them without authentication.

Is my system at risk if it is on an internal network?

According to Halo Surface Signal, this software is intended for use within private, internal network segments. While the vulnerability is reachable over a network, public-facing deployments are considered uncommon. Your risk level depends on whether your OpenNMS instance has been inadvertently exposed to the public internet, which would significantly widen the potential attack surface.

What are the first steps to address this issue?

Begin by auditing your infrastructure to locate all active OpenNMS Meridian or Horizon instances. Confirm their network accessibility to determine if any are exposed externally. Once identified, prioritize these instances based on their business criticality and exposure level, then plan to upgrade to the specified patched versions (Meridian 2024.3.14, 2025.0.11, 2026.0.1 or Horizon 36.0.5) to implement the required security filter changes.

References

github.com/OpenNMS/opennms/pull/8934

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.