LibreNMS EUVD-2026-72384

Requires network reachability to the LibreNMS REST API of an instance running a version before 26.8.0, with at least one valid API token present whose stored hash begins with a digit so it coerces to one of the integers 0-9 the attacker submits. No authentication, credentials, or user interaction are needed (PR:N/UI:N). The limiting factor is the probabilistic AT:P condition: exploitation only succeeds against tokens whose hash coerces to a small integer, so an instance with no API tokens, or tokens that do not coerce, may resist the specific 0-9 payloads.

The signals align on high priority: CVSS 4.0 base 9.2 with AV:N/AC:L/PR:N/UI:N and full VC:H/VI:H/VA:H, meaning network-reachable, unauthenticated, high-impact. The only friction is AT:P (a present attack requirement) - exploitation depends on a stored token hash coercing to one of the ten small integers tried, so success is probabilistic per instance rather than universal, which is why an independent CVSS 3.1 mapping warrants AC:H rather than AC:L. Even so, the attacker can iterate 0-9 cheaply and the payoff (device credentials plus alert-template RCE) is severe, so this is a genuine priority rather than an inflated high-CVSS finding; any internet-exposed or shared-network LibreNMS instance should be patched urgently. No EPSS or CISA KEV data was provided, and no public exploit code is identified at time of analysis - absence of those signals does not reduce the urgency given the low complexity and clear technical writeup from VulnCheck.

An unauthenticated attacker who can reach the LibreNMS web interface sends REST API requests using a numeric token value (iterating 0 through 9) until MySQL type coercion matches a stored token hash, granting API access. From there the attacker reads stored device SNMP/SSH credentials and modifies an alert template to execute arbitrary commands on the monitoring host, pivoting into the managed network.