CVE-2026-26988: Critical SQL Injection in LibreNMS ajax_table.php Endpoint

LibreNMS versions 25.12.0 and earlier contain a critical SQL injection vulnerability within the ajax_table.php endpoint. The flaw resides specifically in the IPv6 address search functionality, where user-supplied input is not properly sanitized or parameterized before being used in database queries.

The application processes network address searches by parsing an address parameter. When handling IPv6 searches, the backend logic incorrectly isolates the CIDR prefix and appends it directly to a raw SQL statement. This architectural oversight exposes the database to arbitrary command execution.

Unauthenticated remote attackers can exploit this weakness by sending crafted HTTP requests containing SQL payloads. Successful exploitation permits unauthorized read and write operations against the underlying LibreNMS database, compromising the integrity and confidentiality of the network monitoring system.

The root cause of CVE-2026-26988 lies in the legacy implementation of the address-search.inc.php file. This script was designed to handle asynchronous table population requests for network address searches.

When processing the address parameter, the application attempts to identify and separate a CIDR prefix. It uses the PHP explode function to split the input string at the first slash character (/). The second element of the resulting array is assigned to the $prefix variable.

For queries where the search_type parameter is specified as ipv6, the application constructs a raw SQL query string. If the $prefix variable is not empty, the script concatenates it directly into the WHERE clause of the SQL statement using string interpolation.

The application performs no subsequent validation, sanitization, or type checking on the $prefix variable before database execution. Because the input escapes the bounds of the intended string literal, the underlying database interpreter processes the injected payload as executable SQL syntax.

The vulnerability exists in the legacy request routing mechanism of LibreNMS. The vulnerable code block extracts the prefix from the user input and immediately integrates it into the query structure.

if (str_contains($address, '/')) {
    [$address, $prefix] = explode('/', $address, 2);
}
 
// Vulnerable string concatenation
if (! empty($prefix)) {
    $sql .= " AND ipv6_prefixlen = '$prefix'";
}

The patch introduced in commit 15429580baba03ed1dd377bada1bde4b7a1175a1 fundamentally restructures this functionality. The maintainers deprecated the procedural PHP script in favor of a modern Laravel-based controller architecture, utilizing the Eloquent Object-Relational Mapper (ORM).

// app/Http/Controllers/Table/AddressSearchController.php (Patched)
if (isset($cidr)) {
    $q->where($this->cidrField, $cidr);
}

By utilizing Laravel's Query Builder ($q->where()), the database abstraction layer automatically parameterizes the $cidr input. This parameterization ensures that the database driver treats the user input strictly as a data literal, eliminating the possibility of SQL syntax manipulation.

Exploitation of CVE-2026-26988 requires sending a single HTTP POST request to the ajax_table.php endpoint. The attacker must format the request payload to satisfy the vulnerable code paths in the address parsing logic.

The required parameters include id set to address-search and search_type set to ipv6. The malicious payload is delivered via the address parameter. The attacker begins the input with a valid IPv6 format followed by a slash, satisfying the explode condition, and appends the SQL injection string.

POST /ajax_table.php HTTP/1.1
Host: [TARGET]
Content-Type: application/x-www-form-urlencoded
 
id=address-search&search_type=ipv6&address=::1/64' UNION SELECT 1,2,3,4,5,6,user(),8,9,10,11,12--

A functional Proof-of-Concept exploit is publicly available on GitHub. This script automates the payload delivery and validates the database response, confirming that the injected UNION SELECT statement successfully executes and returns arbitrary data to the HTTP response body.

The primary impact of this vulnerability is complete compromise of the database layer. An attacker can execute arbitrary read queries to extract sensitive configuration data, user credentials, and network topology information stored within the LibreNMS database.

Depending on the database user permissions assigned to the LibreNMS application, the attacker may also execute write operations. This capability permits the modification of administrative credentials, the insertion of rogue monitoring endpoints, or the alteration of system logs to mask malicious activity.

The National Vulnerability Database calculates a CVSS v3.1 base score of 9.1 (Critical) for this flaw. This score reflects the minimal complexity required to exploit the vulnerability remotely without prior authentication.

While the Exploit Prediction Scoring System (EPSS) currently indicates a low probability of widespread automated exploitation (0.02nd percentile), the availability of a functional public PoC significantly alters the immediate risk profile for internet-facing instances.

The standard remediation for CVE-2026-26988 is an immediate upgrade to LibreNMS version 26.2.0 or later. This release completely removes the vulnerable procedural code and transitions the endpoint to a secure, parameterized MVC architecture.

Administrators must apply the patch via the standard LibreNMS update mechanism. Depending on the local installation environment, this typically involves executing the daily.sh script or pulling the latest release tags from the official GitHub repository.

If immediate patching is not technically feasible, network administrators should restrict access to the LibreNMS web interface. The monitoring portal should not be exposed directly to the public internet. Access should be mediated through a Virtual Private Network (VPN) or restricted to trusted internal administrative IP ranges.

Deploying Web Application Firewall (WAF) rules that inspect HTTP POST bodies for common SQL injection signatures targeting the ajax_table.php URI provides temporary defensive coverage. However, these signatures are prone to bypass techniques and do not resolve the underlying code defect.