LibreNMS CVE-2025-68614

Exploitation requires a valid LibreNMS API token authorized to create or update alert rules (POST/PUT to /api/v0/rules) - alert-rule management is an administrative capability, so attacker-side privilege is required (aligning with ZDI's PR:H). The payload only survives through the API path: the web UI already strips HTML tags from the rule name, so UI-created rules are not affected. Triggering requires a second authenticated user (typically an admin) to navigate to the Alerts > Alert Rules page (UI:R), where the jquery-bootgrid component decodes the e()/htmlentities XML character references and reintroduces the live markup into the DOM - meaning the standard output encoding is present but defeated by client-side re-decoding. Limiting factors: attacker needs privileged API access, victim must view the specific page, and only versions prior to 25.12.0 are affected.

This is a stored cross-site scripting flaw (CWE-79) in the LibreNMS Alert Rule API, best characterized as a moderate-severity, authentication-gated issue rather than a top-tier emergency. The NVD CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N = 5.4) indicates network-reachable, low-complexity exploitation but requires some level of privilege (PR:L) and victim interaction (UI:R), with limited confidentiality/integrity impact and no availability impact. The vendor/ZDI disagree materially on two metrics: ZDI scored it 4.3 using PR:H (admin), S:U (unchanged scope), and A:L - so the two authoritative sources CONFLICT on privilege level and scope. Because alert-rule management in LibreNMS is an administrative function and the vector is API-only, the ZDI PR:H assessment is arguably more realistic; verify the required privilege level against your deployment's RBAC. EPSS is 3.88% (90th percentile), which is elevated for a stored XSS but still a minority probability - the high percentile reflects the existence of public POC code more than mass automated exploitation. POC code is publicly available (ZDI/GHSA), but the CVE is NOT in CISA KEV and there is no evidence of active exploitation. Net: a legitimate patch-soon item for LibreNMS operators, not a drop-everything issue - the privilege requirement, need for victim interaction, and absence of KEV listing all cap real-world risk.

An attacker holding a valid LibreNMS API token creates or updates an alert rule via POST/PUT to /api/v0/rules, setting the rule name to a payload such as <script>alert(1)</script>, which the API stores without the tag-stripping applied by the web UI. When another user (typically an administrator) later browses to Alerts > Alert Rules, the jquery-bootgrid table-rendering routine decodes the HTML-encoded name and injects it into the DOM, executing the attacker's script in the victim's authenticated session. A POC is publicly available via the ZDI/GitHub security advisory.