LibreNMS EUVD-2026-97659

Exploitation requires the LibreNMS server to be configured in 'ldap-authorization' or 'ad-authorization' authentication mode AND for the REMOTE_USER variable to not be forwarded (i.e., no upstream authenticating proxy/SSO populating it). Under those conditions, an unauthenticated remote attacker simply supplies a wildcard username via the HTTP Basic Authorization header (PHP_AUTH_USER), which is injected unescaped into the LDAP search filter (CWE-90); because authentication only verifies that a matching entry exists, the wildcard matches all users/groups and yields admin. LIMITING FACTORS: installations using other auth backends (e.g., mysql/local), or those where a front-end proxy correctly sets REMOTE_USER, are not exploitable via this path - this is why the CVSS 4.0 vector carries AT:P. No user interaction or prior authentication is needed once the vulnerable mode is in use.

This is a genuine high-priority issue rather than an inflated CVSS score. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) describes a network-reachable, low-complexity, unauthenticated flaw with full high impact to confidentiality, integrity and availability (VC:H/VI:H/VA:H), and the authentication-bypass-to-admin outcome in the description corroborates that triad. The one tempering signal is AT:P (attack requirements present), which reflects the real preconditions: the server must run in ldap-authorization or ad-authorization mode and REMOTE_USER must not be forwarded. No EPSS score, no KEV listing, and no public exploit were provided in the input, so exploitation status is 'no public exploit identified at time of analysis' - exploitability here is inferred from the CVSS vector and description, not from an observed exploit. The absence of EPSS/KEV data is a gap, not evidence of low risk; given a trivially crafted wildcard-username request yielding admin, real-world risk for exposed, LDAP-backed LibreNMS instances is high, but defenders should confirm exploitation telemetry independently since none was supplied.

An attacker reaches an internet- or network-exposed LibreNMS instance configured for LDAP/AD authorization where no upstream SSO populates REMOTE_USER. They send an HTTP request with a Basic Authorization header carrying a wildcard username (e.g. '*') in PHP_AUTH_USER; because usernames are inserted unescaped into the LDAP search filter and only existence is checked, the wildcard matches all users and groups and the attacker is granted administrative access. No public exploit code is referenced, but the technique is straightforward to reproduce from the advisory.