CVE-2026-84189: LibreNMS before 26.7.0 Stored XSS via Oxidized API
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
LibreNMSto a version that resolves this vulnerability.Fixed in 26.7.0 - Configuration
Ensure JSON fields returned by the Oxidized integration URL (oxidized.url) are rendered on the device showconfig tab with htmlspecialchars() to prevent stored/persistent XSS (fields include name, ip, model, author, commit message) as the fix for versions before 26.7.0.
LibreNMS Oxidized integration (oxidized.url) htmlspecialchars() = applied
Event History
Frequently Asked Questions
Who is exposed to this issue?
LibreNMS instances through 26.4.0 are exposed when the administrator-configurable oxidized.url integration endpoint is set to an attacker-controlled server. The resulting persistent XSS affects users who view any device's showconfig tab.
What does an attacker need to exploit it?
An administrator must first configure the Oxidized integration URL to point to an attacker-controlled server. That server can then return malicious JSON values in fields such as name, ip, model, author, or commit message, which LibreNMS renders without HTML escaping.
Is the default configuration affected?
The available information identifies exploitation through the admin-configurable oxidized.url integration URL. It does not state that a default Oxidized configuration points to an attacker-controlled endpoint.
What can be done if upgrading is not immediately possible?
Do not configure oxidized.url to an attacker-controlled or otherwise untrusted server. Restrict that integration endpoint to trusted Oxidized services and prevent it from being redirected to attacker-controlled infrastructure.
How can I determine whether the issue may already have been triggered?
Review the configured oxidized.url value and determine whether it has pointed to an attacker-controlled or untrusted server. Also inspect device showconfig pages for unexpected content originating from Oxidized JSON fields, including name, ip, model, author, and commit message.