CVE-2026-86426 in LibreNMSinfo

Summary

by MITRE • 09/07/2026

LibreNMS before 26.8.0 contains an authentication bypass vulnerability in the REST API that allows unauthenticated attackers to access protected endpoints by sending numeric values instead of string tokens. Attackers can exploit MySQL type coercion by sending small integers like 0 through 9 to match token hashes, gaining access to API functionality including device credentials and administrative features that enable remote code execution through alert templates.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Analysis

by VulDB Data Team • 09/07/2026

The vulnerability identified in LibreNMS versions prior to 26.8.0 represents a critical authentication bypass within the REST API subsystem, stemming from improper handling of input data types during token validation. The core technical flaw lies in how the application processes authentication tokens submitted via HTTP requests. Specifically, the backend logic fails to strictly enforce string type constraints when comparing user-supplied values against stored cryptographic hashes. This oversight allows attackers to exploit MySQL's implicit type coercion behavior, where numeric inputs are automatically converted or compared as integers rather than strings during hash matching operations. By submitting small integer values such as zero through nine, an attacker can trigger a condition where the hashed representation of these numbers coincidentally matches the expected token format or passes validation checks due to loose comparison operators in the database query layer. This mechanism effectively circumvents the intended authentication gatekeeping, granting unauthenticated access to endpoints that are supposed to require valid session tokens for operation.

The operational impact of this vulnerability is severe because it provides a direct pathway from remote network access to full administrative control over the monitoring infrastructure. Once an attacker successfully bypasses authentication using these numeric payloads, they gain unrestricted access to sensitive API functionality. This includes the ability to retrieve device credentials, which may contain passwords or keys for network devices monitored by LibreNMS, thereby compromising the broader IT environment. Furthermore, the compromised account allows interaction with administrative features that are not typically exposed to unauthenticated users. A particularly dangerous consequence is the capability to manipulate alert templates. Since these templates can execute arbitrary commands when triggered, an attacker can inject malicious code into them. This leads directly to remote code execution on the server hosting LibreNMS, allowing for complete system compromise, data exfiltration, and potential lateral movement within the internal network.

From a classification perspective, this vulnerability aligns with CWE-287, which describes Improper Authentication, specifically highlighting failures in verifying identity due to weak input validation or type coercion issues. It also relates closely to CWE-94, Code Injection, as the exploitation chain culminates in arbitrary code execution through alert template manipulation. In terms of adversary tactics, this exploit maps to MITRE ATT&CK technique T1078, Valid Accounts, where attackers use legitimate credentials or bypass authentication mechanisms to maintain access. Additionally, the ability to execute commands via templates corresponds to T1505, Server Software Component, indicating an attempt to establish persistence or execution capabilities within a trusted software component. The reliance on MySQL type coercion also touches upon CWE-697, Incorrect Comparison, emphasizing the danger of relying on implicit conversions in security-critical comparisons.

Mitigation strategies must prioritize immediate patching and strict input validation. Organizations running LibreNMS should upgrade to version 26.8.0 or later, where this authentication bypass has been resolved by enforcing strict type checking for API tokens. Until patches are applied, network-level controls such as Web Application Firewalls can be configured to block requests containing numeric patterns in token fields if the application architecture allows it, although this is a less reliable workaround than patching. Developers and administrators should also audit other areas of the codebase that interact with database queries for similar loose comparison practices, ensuring that all user-supplied data intended for authentication or authorization checks is explicitly cast to strings before processing. Regular security assessments focusing on API endpoints are recommended to detect any residual weaknesses in input handling logic across the application stack.

Responsible

VulnCheck

Reservation

09/07/2026

Disclosure

09/07/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

low

Sources

Do you know our Splunk app?

Download it now for free!