GHSA-7cj5-v4pp-v632: Stored Cross-Site Scripting in LibreNMS Graph Descriptions

LibreNMS is an open-source, auto-discovering PHP/MySQL-based network monitoring system that utilizes SNMP to discover and graph network infrastructure. To maintain robust reporting, the platform provides administrators with configuration options to customize descriptions and attributes of various graph types. This administrative capability exposes an attack surface when system configurations are rendered to other web session contexts.

The administrative settings for graph descriptions, mapped to graph_descr.<graphtype>, allow administrators to input arbitrary string configurations. These settings are subsequently queried and rendered dynamically when users navigate to different graph sections of the application.

This vulnerability is classified under CWE-79 (Improper Neutralization of Input During Web Page Generation). Because the application retrieves and outputs these descriptions verbatim to the DOM, an attacker with administrative privileges can store malicious payloads, which are executed automatically when other users load the associated graph dashboard.

The underlying vulnerability is located within the presentation layer of the application, specifically in the file includes/html/pages/graphs.inc.php at line 194. The application dynamically processes requests for various graph types by analyzing URL and request parameters stored inside the $vars array.

To display custom graph descriptions, the application uses the dynamic configuration retrieval method LibrenmsConfig::get('graph_descr.' . $vars['type']). This function queries the system database and returns the configured value for the specified graph type. The returned value is then passed directly to the standard output buffer.

The application fails to invoke sanitation, filtering, or context-aware escaping functions before displaying this data. Because the output mechanism lacks context-aware encoding, the user browser interprets any stored string containing HTML elements or executable JavaScript tags as functional code instead of plain text.

The vulnerability is demonstrated by examining the execution flow in the unpatched version of includes/html/pages/graphs.inc.php:

// Vulnerable Code: includes/html/pages/graphs.inc.php (Line 194)
// The retrieved configuration string is echoed directly to the output buffer without escaping.
echo LibrenmsConfig::get('graph_descr.' . $vars['type']);

To resolve this vulnerability, developers introduced a security patch that forces strict output encoding on the retrieved data before it is written to the browser context:

// Patched Code: includes/html/pages/graphs.inc.php (Line 194)
// The output is processed by htmlspecialchars with ENT_QUOTES to sanitize special characters.
echo htmlspecialchars(LibrenmsConfig::get('graph_descr.' . $vars['type']), ENT_QUOTES, 'UTF-8');

The implementation of htmlspecialchars() with the ENT_QUOTES flag and UTF-8 encoding ensures that characters such as <, >, &, ", and ' are safely converted to their corresponding HTML entity equivalents. This prevents the browser from interpreting the injected string as executable HTML tags or event handlers, effectively neutralizing the injection vector.

The fix is robust and complete for this specific rendering location. However, security teams should verify that other configuration rendering paths within the LibreNMS application code apply the same strict output escaping methodologies.

Exploiting this vulnerability requires network connectivity to the LibreNMS administrative interface and valid administrator credentials. The attack consists of a two-stage process: payload injection (persistence) and payload execution (victim trigger).

During the injection phase, the administrator sends an authenticated PUT request to update the graph description configurations. The endpoint accepts raw configurations, including HTML tags and event handlers. The payload is successfully written to the system database.

PUT /settings/graph_descr.device_processor HTTP/1.1
Host: <target-ip>
Content-Type: application/json
X-Requested-With: XMLHttpRequest
Authorization: Bearer <token>
 
{"value": "<img src=x onerror=\"alert('ADV-15')\">"}

When a victim visits the graphs page associated with the modified graph type (in this case, device_processor), their browser issues a GET request. The server queries the database, extracts the unescaped payload, and embeds it directly into the HTML response body. The browser processes the broken image element, fails to load the source, and triggers the onerror JavaScript handler in the victim's session context.

GET /graphs?type=device_processor HTTP/1.1
Host: <target-ip>
Authorization: Bearer <victim-token>

The impact of a successful exploitation of this vulnerability is significant, despite requiring administrative privileges. While administrators already have elevated control over the platform, stored XSS allows them to cross session boundaries and execute actions in the context of other authenticated users.

In scenarios where multiple administrators manage a LibreNMS instance, a lower-trust administrator or a compromised administrative account can leverage this vulnerability to hijack sessions of other, higher-privileged system administrators. This facilitates privilege escalation and unauthorized operational actions.

Because the session cookies of other active users can be extracted via document.cookie (if HttpOnly is not enforced), an attacker can perform administrative actions on behalf of the victim. This includes modifying system configurations, managing users, or querying detailed network infrastructure data.

The primary remediation strategy is upgrading the LibreNMS installation to version 26.7.0 or higher. This release contains the necessary codebase patches to sanitize dynamic configurations before output rendering.

For deployments where immediate upgrading is not possible, security administrators can apply the manual source code modification to includes/html/pages/graphs.inc.php. Ensure that htmlspecialchars() is integrated on line 194.

In addition to patching, organizations should implement defense-in-depth measures such as a strict Content Security Policy (CSP). Restricting inline scripts via policies like script-src 'self' prevents the execution of arbitrary JavaScript injected into the DOM, mitigating the operational impact of stored XSS vulnerabilities.