CVE-2026-109353 in LibreNMS
Summary
by MITRE • 10/12/2026
LibreNMS before 26.9.0 contains an SQL injection vulnerability that allows unprivileged users to inject SQL by supplying an array-valued notification_id parameter to notifications.inc.php. Attackers can perform cross-table reads of users.password hashes, with results persisted in notifications_attribs and readable through the interface.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified in LibreNMS versions prior to 26.9.0 represents a critical security flaw rooted in improper input validation within the application's notification handling subsystem. Specifically, the defect resides in the file notifications.inc.php, where the system fails to adequately sanitize or parameterize an array-valued parameter named notification_id before incorporating it into SQL queries. This lack of robust data type checking and query construction allows unauthenticated or low-privilege users to manipulate the structure of database commands executed by the backend application server. By supplying a specially crafted array instead of expected scalar values, attackers can break out of the intended logical context of the query, effectively injecting arbitrary Structured Query Language statements that are then processed directly by the underlying relational database management system.
From a technical perspective, this flaw is classified as an SQL Injection vulnerability, aligning with CWE-89 in the Common Weakness Enumeration taxonomy. The core issue stems from the application's assumption that input parameters will strictly adhere to expected data types and formats without rigorous verification. When the notification_id parameter is passed as an array, the PHP code likely iterates over its elements or concatenates them into a query string without proper escaping. This behavior enables attackers to append additional SQL clauses to the original statement. The exploitation does not require administrative privileges; rather, it leverages the default permissions of standard user accounts within LibreNMS, making it accessible to any individual with valid login credentials for low-level access or potentially unauthenticated users if authentication mechanisms are bypassed in specific configurations.
The operational impact of this vulnerability is severe due to its potential for data exfiltration and persistence. Attackers can exploit the injection point to perform cross-table reads, specifically targeting sensitive user credential stores such as password hashes stored in the users table. Unlike many SQL injection vulnerabilities that result in immediate error-based disclosure or denial of service, this particular flaw allows for a more stealthy attack vector where extracted data is persisted within the notifications_attribs database table. This persistence mechanism ensures that stolen information remains accessible through the application's native interface long after the initial exploitation event. Consequently, an attacker can systematically harvest password hashes and other sensitive user attributes by manipulating notification records, turning a transient injection into a sustained data breach channel without triggering immediate alarms associated with anomalous query patterns or system crashes.
This behavior also exhibits characteristics of stored SQL injection, where malicious payloads are saved within the application's database for later execution via legitimate interface interactions. This aligns with ATT&CK techniques related to Data from Local System and potentially T1059 if further command execution is chained through subsequent exploitation steps involving retrieved credentials. The ability to read password hashes facilitates offline cracking attacks, which can lead to full account compromise across the network if users employ weak or reused passwords. Furthermore, access to these internal tables may reveal additional metadata about system configuration, user roles, and other infrastructure details that aid in deeper lateral movement within the target environment.
Mitigation strategies must prioritize immediate patching of LibreNMS to version 26.9.0 or later, where this input validation flaw has been addressed by developers through stricter type checking and parameterized query implementations. In environments where upgrading is not immediately feasible, network-level controls such as Web Application Firewalls can be configured to detect and block requests containing array-valued parameters in contexts expecting scalar values, although this may introduce false positives requiring careful tuning. Additionally, database access permissions should be reviewed to ensure that the application's database user account operates under the principle of least privilege, restricting direct table access where possible. Regular audits of input handling logic across all PHP files are recommended to identify similar patterns of unsafe query construction and enforce standardized sanitization protocols throughout the codebase.