CVE-2025-68614 in LibreNMS
Summary
by MITRE • 12/23/2025
LibreNMS is an auto-discovering PHP/MySQL/SNMP based network monitoring tool. Prior to version 25.12.0, the Alert Rule API is vulnerable to stored cross-site scripting. Alert rules can be created or updated via LibreNMS API. The alert rule name is not properly sanitized, and can be used to inject HTML code. This issue has been patched in version 25.12.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 01/02/2026
The vulnerability identified as CVE-2025-68614 affects LibreNMS, a widely-used network monitoring solution that leverages PHP, MySQL, and SNMP technologies to provide automated network discovery and monitoring capabilities. This tool serves as a critical component in enterprise network management, enabling administrators to track device performance, detect anomalies, and respond to network issues through automated alerting mechanisms. The affected system operates within the alert rule management functionality, which allows network administrators to define specific conditions that trigger notifications when network events occur. These alert rules form the backbone of the system's monitoring capabilities, making their integrity crucial for maintaining the security and reliability of the entire monitoring infrastructure.
The technical flaw resides in the Alert Rule API's insufficient input validation and sanitization mechanisms specifically targeting the alert rule name field. When administrators create or update alert rules through the API, the system fails to properly sanitize the rule name parameter, allowing malicious actors to inject arbitrary HTML code into this field. This represents a classic stored cross-site scripting vulnerability where the malicious payload is permanently stored within the application's database and subsequently served to other users who view the alert rule. The vulnerability stems from the application's failure to implement proper output encoding or input validation on user-supplied data before it is persisted in the database. This weakness enables attackers to craft specially crafted alert rule names containing malicious script tags that execute when other users browse the alert rule interface.
The operational impact of this vulnerability extends beyond simple data corruption or display issues, presenting significant security risks to organizations relying on LibreNMS for network monitoring. An attacker who gains the ability to create or modify alert rules through the API could inject malicious scripts that steal session cookies, redirect users to malicious sites, or execute unauthorized actions within the context of the victim's browser session. This vulnerability could be exploited by attackers who have gained access to the LibreNMS API through various attack vectors such as weak authentication, unauthorized API access, or other pre-existing vulnerabilities. The stored nature of the XSS payload means that the malicious code persists even after the initial injection, potentially affecting multiple users over extended periods until the alert rule is deleted or the system is updated.
Organizations utilizing LibreNMS must prioritize immediate remediation through the upgrade to version 25.12.0, which implements proper input sanitization and output encoding mechanisms for alert rule names. This update addresses the root cause by ensuring that user-supplied data undergoes rigorous validation and sanitization before being stored in the database. System administrators should also implement additional security measures including API access controls, monitoring for unauthorized alert rule modifications, and regular security assessments of the monitoring infrastructure. The vulnerability aligns with CWE-79, which specifically addresses cross-site scripting flaws, and represents a significant risk under the ATT&CK framework's privilege escalation and persistence tactics. Organizations should conduct comprehensive security audits of their network monitoring systems and ensure proper access controls are in place to prevent unauthorized modification of critical alerting configurations. The fix demonstrates proper application of security principles including input validation, output encoding, and defense-in-depth measures to protect against persistent cross-site scripting attacks.