CVE-2026-108715 in LibreNMS
Summary
by MITRE • 10/11/2026
LibreNMS through 26.9.1.1 contains an authorization bypass vulnerability in includes/html/graphs/smokeping/auth.inc.php that checks the src probe device instead of the rendered target device. Restricted users permitted on a probe device can request smokeping_in or smokeping_out graphs with arbitrary device ids to view latency data and enumerate device names.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/11/2026
The vulnerability identified in LibreNMS versions up through 26.9.1.1 represents a critical authorization bypass within the network monitoring application's graphing subsystem. Specifically, this flaw resides in the file includes/html/graphs/smokeping/auth.inc.php, which is responsible for validating user permissions before generating SmokePing latency graphs. The core technical deficiency lies in the logic used to determine access rights; rather than verifying that the authenticated user has permission to view data associated with the specific target device being rendered in the graph, the system incorrectly validates authorization against the source probe device configured for the monitoring task. This architectural misalignment creates a significant security gap where the identity of the entity performing the measurement is prioritized over the identity of the entity whose data is being accessed.
From an operational perspective, this logic error allows restricted or unprivileged users to exploit the discrepancy by manipulating request parameters. By supplying arbitrary device identifiers in their requests for smokeping_in or smokeping_out graphs, these lower-privilege accounts can bypass access controls and retrieve latency metrics intended only for authorized personnel. The ability to view detailed network performance data for devices outside of one's assigned scope constitutes a severe breach of confidentiality within the monitoring infrastructure. This is not merely an information disclosure issue but also facilitates reconnaissance activities that can aid further attacks against the network.
The impact of this vulnerability extends beyond simple data leakage. Attackers with limited access rights can use the exposed latency data to map out the internal network topology and identify critical assets based on their responsiveness and connectivity patterns. This enumeration capability allows adversaries to discover device names, infer network segments, and potentially pinpoint high-value targets for subsequent exploitation attempts. The exposure of such granular operational intelligence undermines the principle of least privilege that LibreNMS is designed to enforce, effectively rendering role-based access controls ineffective for this specific functionality.
This vulnerability aligns with CWE-269, which classifies Improper Privilege Management, as it involves a failure to correctly assign and verify user privileges during execution. Furthermore, in the context of the MITRE ATT&CK framework, this behavior corresponds to techniques related to Discovery, specifically Network Service Scanning or Account Enumeration, where an attacker gathers information about network services and connected devices to plan further intrusions. The exploitation relies on manipulating input parameters to bypass authentication checks, which is characteristic of Broken Access Control vulnerabilities often found in web applications that fail to properly validate object-level permissions against the requesting user's role.
To mitigate this risk, administrators must upgrade LibreNMS to a version later than 26.9.1.1 where the authorization logic has been corrected to verify access rights based on the target device rather than the probe source. Until an update is applied, network segmentation and strict firewall rules can help limit exposure of the web interface to untrusted networks. Additionally, implementing Web Application Firewalls with specific rule sets for LibreNMS endpoints may provide a temporary layer of defense by detecting and blocking requests that attempt to access resources outside of expected parameter ranges or user permissions. Regular auditing of user roles and ensuring that monitoring probes are assigned only to devices within their authorized scope can also reduce the attack surface associated with this flaw.