CVE-2026-26990: Verified Repro With Script Download

CVE-2026-26990: LibreNMS Time-Based Blind SQL Injection in address-search.inc.php

Summary

A time-based blind SQL injection vulnerability exists in LibreNMS's address-search.inc.php file via the address parameter. When a crafted subnet prefix is supplied (e.g., 127.0.0.1/aa<SQL injection>), the prefix value is extracted by splitting on the / character and then concatenated directly into SQL queries without proper sanitization or parameter binding. This allows any authenticated user to manipulate query logic and infer database information through time-based conditional responses using SLEEP() functions.

Impact

Package: librenms/librenms (Composer)
Affected Versions: < 26.2.0
Fixed Version: 26.2.0
CVE ID: CVE-2026-26990
CVSS Score: 8.8 (HIGH)
CWE: CWE-89 (Improper Neutralization of Special Elements used in an SQL Command)

Risk Level and Consequences:

• Any authenticated user can exploit this vulnerability
• Time-based blind SQL injection allows extraction of sensitive database information
• Attacker can retrieve privileged accounts and password hashes
• Potential for privilege escalation within LibreNMS
• Database schema information can be enumerated

Root Cause

The vulnerability exists in includes/html/table/address-search.inc.php where user-controlled input from the address parameter is processed as follows:

1. The address parameter is split on / character:

   [$address, $prefix] = explode('/', $address, 2);
   

2. The $prefix variable is then directly concatenated into SQL queries without sanitization:

   // Line 34 - IPv4 query
   $sql .= " AND ipv4_prefixlen='$prefix'";
   
   // Line 52 - IPv6 query
   $sql .= " AND ipv6_prefixlen = '$prefix'";
   

3. While the $address variable uses proper parameter binding with ? placeholders, the $prefix variable is concatenated directly using string interpolation, allowing SQL injection.

Fix Commit: The vulnerability was fixed by completely refactoring the address search functionality to use Laravel Controllers with Eloquent ORM and proper parameter binding:

• Old file: includes/html/table/address-search.inc.php (removed)
• New files:
  • app/Http/Controllers/Table/AddressSearchController.php
  • app/Http/Controllers/Table/Ipv4AddressSearchController.php
  • app/Http/Controllers/Table/Ipv6AddressSearchController.php

The fixed code uses:

if (isset($cidr)) {
    $q->where($this->cidrField, $cidr);
}

This leverages Laravel's query builder which automatically uses prepared statements with bound parameters.

Reproduction Steps

Reference: repro/reproduction_steps.sh

The script performs the following:

1. Locates the vulnerable file in the cloned vulnerable version (26.1.0)
2. Identifies vulnerable code patterns by searching for unsanitized $prefix usage
3. Extracts and displays the vulnerable code sections showing the SQL concatenation
4. Analyzes the injection vector explaining how the address parameter is split and exploited
5. Compares with the fixed version showing the proper parameter binding approach
6. Writes detailed evidence to logs/reproduction_evidence.txt

Expected Evidence:

• Vulnerability confirmation messages showing lines 34 and 52 with unsanitized $prefix
• Code extraction showing the vulnerable SQL building logic
• Evidence file documenting the complete vulnerability

Evidence

Log Files:

• logs/reproduction_evidence.txt - Detailed vulnerability documentation

Key Excerpts:

From includes/html/table/address-search.inc.php (line 34):

if (! empty($prefix)) {
    $sql .= " AND ipv4_prefixlen='$prefix'";
}

From includes/html/table/address-search.inc.php (line 52):

if (! empty($prefix)) {
    $sql .= " AND ipv6_prefixlen = '$prefix'";
}

Environment Details:

• Vulnerable Version: LibreNMS 26.1.0
• Fixed Version: LibreNMS 26.2.0
• Vulnerable File: includes/html/table/address-search.inc.php
• Endpoint: /ajax_table.php with id=address-search

Sample Exploit Payload:

POST /ajax_table.php
Parameters:
  id=address-search
  search_type=ipv4
  address=127.0.0.1/aa' AND (SELECT 1 FROM (SELECT IF(ASCII(SUBSTRING((SELECT CURRENT_USER()),1,1))=64,SLEEP(1.5),0))x) AND '1'='1

Recommendations / Next Steps

Immediate Actions:

1. Upgrade to LibreNMS 26.2.0 or later - This is the recommended fix as it replaces the vulnerable code with properly parameterized queries

2. If immediate upgrade is not possible:

   • Apply input validation to the address parameter
   • Use prepared statements for the $prefix variable
   • Implement strict prefix validation (only allow numeric CIDR values)

Testing Recommendations:

1. Run the reproduction script repro/reproduction_steps.sh to verify the vulnerability in your environment
2. After upgrading, verify that the includes/html/table/address-search.inc.php file no longer exists (replaced by controllers)
3. Test that address search functionality still works correctly after the upgrade
4. Monitor logs for any SQL injection attempts targeting the /ajax_table.php endpoint

Security Hardening:

1. Implement Web Application Firewall (WAF) rules to detect SQL injection patterns in the address parameter
2. Enable SQL query logging to detect suspicious queries
3. Apply principle of least privilege to database users
4. Regularly update LibreNMS to the latest stable version

Additional Notes

Idempotency Confirmation: The reproduction script has been verified to run successfully multiple times consecutively, producing consistent results. The script is self-contained and does not modify the source code, ensuring it can be run repeatedly without side effects.

Edge Cases and Limitations:

• The reproduction script performs static code analysis rather than dynamic exploitation, as dynamic testing would require a full LibreNMS installation with database and authentication setup
• The vulnerability requires authentication, so only authenticated users can exploit it
• Both IPv4 and IPv6 search types are affected by this vulnerability
• The MAC address search type (search_type=mac) does not appear to use the $prefix variable

Variant Analysis: The same vulnerable pattern exists in two locations:

1. IPv4 prefix length query (line 34)
2. IPv6 prefix length query (line 52)

Both should be tested when verifying the fix.