Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-10-11T13:17:14.577Z",
  "pubdate": "2026-10-11T13:17:14.577Z",
  "executiveSummary": "An authorization bypass vulnerability exists within LibreNMS versions through 26.9.1.1, specifically affecting the Smokeping graphing component.\nThe vulnerability is located in includes/html/graphs/smokeping/auth.inc.php and allows authenticated, restricted users to view unauthorized latency data.\nThe root cause stems from improper validation logic where the application checks permissions against the source probe device rather than the actual requested target device.\nThis flaw enables attackers to circumvent access control lists (ACLs) to request latency graphs for arbitrary device IDs, facilitating unauthorized information disclosure and network reconnaissance.\nBy manipulating the request parameters for smokeping_in or smokeping_out graphs, a restricted user can enumerate internal device names and monitor latency metrics for devices they are not explicitly permitted to access.\nThe vulnerability requires an authenticated session with restricted privileges. It poses a significant risk to internal network visibility, as it allows unauthorized users to map device infrastructure and assess connectivity performance across the managed network environment.",
  "technicalDetails": "The vulnerability resides in the authorization logic of the Smokeping module, specifically within the file includes/html/graphs/smokeping/auth.inc.php. LibreNMS utilizes this file to determine if a user has sufficient privileges to access latency graph data for a specified device.\nThe primary technical failure occurs during the access control verification phase. Instead of validating the user's permissions against the target device ID requested in the graph generation parameters, the script incorrectly references the source probe device. This validation logic error allows a user who has access to at least one probe device to pass the authorization check while requesting metrics for any other device registered in the LibreNMS database.\nTo exploit this, an attacker with a low-privileged account—who is already granted legitimate access to a single Smokeping probe—can manipulate the HTTP request parameters sent to the Smokeping graphing service. By targeting the smokeping_in or smokeping_out graphing functions, the attacker modifies the device identifier passed in the URL parameters to match a restricted or private device ID. Because the application logic mistakenly performs the ACL check against the authorized probe rather than the restricted target, the request proceeds, and the application generates a graph containing the requested latency data.\nThe attack flow is as follows: 1) The attacker authenticates to LibreNMS with restricted credentials. 2) The attacker identifies a target device ID of interest that is outside their authorized scope. 3) The attacker crafts a request to the smokeping graphing endpoint, specifying the target device ID and selecting the desired latency metric. 4) The server-side script includes/html/graphs/smokeping/auth.inc.php executes, retrieving the session context and the target device ID. 5) The script erroneously validates the user against the probe source, resulting in an 'authorized' state. 6) The application renders the sensitive latency graph, leaking performance metadata to the unauthorized user.\nThe impact of this vulnerability is significant in the context of network reconnaissance. By iterating through device IDs, an attacker can enumerate the hostnames and IP addresses of devices within the LibreNMS inventory, effectively mapping the internal network topology. Furthermore, the leakage of latency data provides insight into the responsiveness and stability of internal assets, which could be leveraged to identify high-value targets or determine active operational hours for network infrastructure."
}