CVE-2022-4069

What it actually does

LibreNMS versions prior to 22.10.0 contain a stored or reflected cross-site scripting weakness where attacker-controlled input is not consistently sanitized before being rendered in the web interface. Because the CVSS vector requires high privileges and user interaction, exploitation generally requires an authenticated, highly privileged LibreNMS user to create or modify content that is later viewed by another user in a browser. Successful exploitation allows JavaScript execution in the victim's LibreNMS session, which can expose page content, perform actions as the victim, alter monitored object metadata, or assist in session theft if cookies or tokens are accessible to client-side script. The flaw does not directly provide server-side code execution or service disruption, but it can compromise confidentiality and integrity within the LibreNMS application context.

Why it matters to the business

An exposed vulnerable LibreNMS instance can allow a malicious or compromised privileged account to attack other users of the monitoring portal. Because LibreNMS often contains sensitive operational visibility into networks, devices, alerts, interfaces, routing, and infrastructure health, successful exploitation may expose monitoring data or enable unauthorized changes through a victim's browser session. The vulnerability is not listed in CISA KEV and has no reported ransomware association in the provided data, but the EPSS score is high, indicating elevated likelihood of exploitation activity compared with many vulnerabilities. Organizations running internet-accessible or broadly accessible LibreNMS should prioritize upgrade validation, especially because the issue has been public for several years.

How an attack unfolds

An attacker first obtains access to a LibreNMS account with sufficient privileges to reach the vulnerable input path. The attacker then submits crafted HTML or JavaScript in a field that LibreNMS later displays in the web UI without proper output encoding. When a targeted administrator or another authenticated user views the affected page, the browser executes the injected script under the trusted LibreNMS origin. The script can read visible data, call LibreNMS application endpoints available to the victim, modify settings or monitored object data within the victim's authorization, or attempt to exfiltrate session-adjacent data to attacker-controlled infrastructure. Exploitation requires user interaction and is constrained to the browser/application context, but it can become a meaningful pivot when LibreNMS is used by network or infrastructure administrators.

How to fix it

Upgrade LibreNMS to version 22.10.0 or later. For Git-based deployments, ensure the deployed code includes commit ddf24809d48485dfdaf70cab1d98eec582674e76 or a later release containing the fix. After upgrading, clear application caches as recommended by LibreNMS maintenance procedures and restart relevant web/PHP services if required by the deployment model. If immediate upgrade is not possible, restrict LibreNMS access to trusted networks or VPN, enforce strong authentication and least privilege for administrative users, reduce the number of highly privileged accounts, and monitor for suspicious script-like input in editable LibreNMS fields. Mitigations reduce exposure but should not be treated as a substitute for applying the fixed version.

How to confirm the fix worked

Confirm the running LibreNMS version is 22.10.0 or later, or confirm that the checked-out Git revision contains ddf24809d48485dfdaf70cab1d98eec582674e76. Review the web application package source or deployment metadata rather than relying only on external banners. Where safe and authorized, test representative user-editable fields by entering benign encoded characters such as angle brackets and quotes and confirming they are rendered as text rather than executable HTML. Verify that web access controls limit the LibreNMS interface to authorized users and networks. Review vulnerability scanner results and software inventory for any remaining LibreNMS installations reporting versions prior to 22.10.0.

Typical attack path

1. Identify a LibreNMS deployment running a version prior to 22.10.0 or a Git revision before ddf24809d48485dfdaf70cab1d98eec582674e76.
2. Gain access to a highly privileged LibreNMS account through credential theft, insider access, password reuse, or another vulnerability.
3. Locate the vulnerable field or workflow that stores or reflects insufficiently sanitized user-controlled content.
4. Submit an XSS payload that will execute when another user views the affected LibreNMS page.
5. Wait for or socially engineer a targeted authenticated user to open the affected page in the LibreNMS interface.
6. Execute JavaScript in the victim's browser session to read page data, issue application requests as the victim, or exfiltrate relevant information.
7. Use any gained access or information to make unauthorized configuration changes, hide monitoring artifacts, or support broader intrusion activity.

How to detect it

Investigate whether suspicious script content was submitted to LibreNMS before the upgrade. Review LibreNMS application logs, web server access logs, reverse proxy or WAF logs, authentication logs, and database-backed audit or change history if available. Focus on POST, PUT, or PATCH requests from authenticated users to pages that create or modify devices, services, alerts, dashboards, maps, notes, custom fields, or other user-rendered content. Look for HTML tags, JavaScript event handlers, encoded script payloads, data URIs, or outbound callback domains embedded in request parameters. Correlate suspicious submissions with subsequent page views by other users and any outbound HTTP/DNS traffic from administrator workstations to unfamiliar domains. Also review account activity for unusual administrative changes after a user viewed the affected page. Because exact public exploit strings are not provided, detection should combine generic XSS payload hunting with LibreNMS-specific authenticated change activity and browser/network telemetry.

• <script
• </script>
• %3Cscript
• %3C%2Fscript%3E
• javascript:
• %6a%61%76%61%73%63%72%69%70%74%3a
• onerror=
• onload=
• onclick=
• onmouseover=
• <img src=x onerror=
• <svg onload=
• document.cookie
• localStorage
• sessionStorage
• fetch(
• XMLHttpRequest
• eval(
• atob(
• btoa(
• new Image().src
• /ajax_form.php
• /device/
• /devices/
• /alerts/
• /alert-rules/
• /dashboard
• /maps/

What your security team should do

• Inventory all LibreNMS deployments, including Git-based and containerized installations, and identify any version prior to 22.10.0.
• Upgrade affected instances to LibreNMS 22.10.0 or later, or deploy a revision that includes commit ddf24809d48485dfdaf70cab1d98eec582674e76.
• Prioritize externally reachable or broadly accessible LibreNMS portals because the EPSS score is high even though the vulnerability is not in CISA KEV.
• Review LibreNMS user roles and remove unnecessary high-privilege accounts, since exploitation requires high privileges.
• Search historical web, application, and reverse-proxy logs for script injection attempts and suspicious outbound callbacks around the LibreNMS interface.
• Audit recent changes made by privileged LibreNMS users, especially edits to device, service, alerting, dashboard, and metadata fields that could contain rendered text.
• Harden the management interface with SSO or MFA, network allowlisting, secure cookie settings, and a restrictive Content Security Policy where compatible.
• Treat evidence of successful XSS as a potential compromise of user sessions and rotate affected credentials or API tokens as appropriate.