CVE-2026-84189 in LibreNMS
Summary
by MITRE • 09/01/2026
LibreNMS through 26.4.0 renders JSON fields (name, ip, model, author, commit message) returned by the admin-configurable Oxidized integration URL (oxidized.url) into the device showconfig page without applying htmlspecialchars(). An administrator who points the Oxidized URL at an attacker-controlled server (SSRF) can cause it to return malicious JSON, resulting in stored/persistent cross-site scripting affecting all users who view any device's showconfig tab. Fixed in 26.7.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified in LibreNMS versions up to and including 26.4.0 represents a critical intersection of server-side request forgery and persistent cross-site scripting, stemming from inadequate input validation within the network monitoring application's configuration management integration. The core technical flaw lies in how the system handles data retrieved from an external source via its Oxidized integration feature. When an administrator configures the oxidized.url parameter to point toward a specific endpoint for retrieving device configurations, LibreNMS fetches JSON-formatted responses containing fields such as name, ip, model, author, and commit message. Crucially, these values are rendered directly into the HTML of the showconfig page without applying necessary encoding functions like htmlspecialchars(). This omission means that any special characters or script tags embedded within the returned JSON data are interpreted by the victim's web browser as executable code rather than static text content.
The operational impact is severe due to the combination of two distinct attack vectors. First, an attacker must induce a privileged user, specifically an administrator, to configure the Oxidized URL setting to point at a server under their control. This constitutes a Server-Side Request Forgery scenario where the application acts as a proxy for malicious requests initiated by the admin interface. Once this configuration is saved and triggered, typically when viewing device configurations, the LibreNMS server retrieves data from the attacker-controlled endpoint. Because the subsequent rendering process lacks proper output encoding, any JavaScript payload injected into those JSON fields becomes persistent within the database or session state associated with that device record. Consequently, every user who subsequently navigates to the showconfig tab for any affected device will have their browser execute the malicious script.
This persistence transforms what might otherwise be a single-session exploitation opportunity into a long-term threat vector affecting all users of the platform. The attack aligns closely with CWE-79, which describes Improper Neutralization of Input During Web Page Generation known as Cross-site Scripting, specifically in its stored variant where malicious scripts are permanently saved on target servers. Furthermore, the initial phase involving the forced server-side request to an attacker-controlled URL maps directly to ATT&CK technique T1187, indicating potential use for further reconnaissance or data exfiltration if combined with other exploits. The ability to execute arbitrary JavaScript in the context of a network monitoring dashboard grants attackers significant capabilities, including session hijacking through cookie theft, credential harvesting via keyloggers embedded in the script, and potentially lateral movement within the internal network by leveraging the administrative privileges often held by users accessing such sensitive infrastructure data.
Mitigation strategies must address both the immediate vulnerability and the underlying architectural weaknesses. The primary remediation is to upgrade LibreNMS to version 26.7.0 or later, where this specific rendering flaw has been corrected with proper output encoding applied to all user-controllable fields before they are inserted into HTML contexts. For environments unable to immediately patch, administrators should strictly validate and sanitize the oxidized.url configuration value to ensure it only points to trusted internal endpoints, thereby preventing SSRF exploitation even if the XSS vector remains theoretically present in older versions. Additionally implementing a Content Security Policy can help mitigate the impact of any successful script execution by restricting the sources from which scripts are allowed to load or execute. Regular auditing of integration configurations and enforcing principle of least privilege for users with access to system settings further reduces the risk surface associated with this class of vulnerabilities.