LibreNMS: Time-Based Blind SQL Injection in address-search

# Root Cause Analysis Report

## 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:
   ```php
   [$address, $prefix] = explode('/', $address, 2);
   ```

2. The `$prefix` variable is then directly concatenated into SQL queries without sanitization:
   ```php
   // 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:
```php
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):
```php
if (! empty($prefix)) {
    $sql .= " AND ipv4_prefixlen='$prefix'";
}
```

From `includes/html/table/address-search.inc.php` (line 52):
```php
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.