Summary
LibreNMS contains an LDAP filter injection vulnerability in its LDAP authorization and Active Directory authorization modes. When usernames are inserted into LDAP queries without escaping, an unauthenticated attacker may submit a wildcard username and bypass authentication checks that only confirm whether a user exists, potentially gaining administrative access.
LibreNMS contains an LDAP filter injection vulnerability in its LDAP authorization and Active Directory authorization modes. When usernames are inserted into LDAP queries without escaping, an unauthenticated attacker may submit a wildcard username and bypass authentication checks that only confirm whether a user exists, potentially gaining administrative access.
Affected context
The issue can arise in LibreNMS deployments using the ldap-authorization or ad-authorization modes when username data is taken from HTTP authentication headers and incorporated into LDAP search filters without appropriate escaping. Risk is higher when REMOTE_USER is not forwarded and the application accepts attacker-controlled values through PHP_AUTH_USER.
The issue can arise in LibreNMS deployments using the ldap-authorization or ad-authorization modes when username data is taken from HTTP authentication headers and incorporated into LDAP search filters without appropriate escaping. Risk is higher when REMOTE_USER is not forwarded and the application accepts attacker-controlled values through PHP_AUTH_USER.
Exploit preconditions
- Attack surface: HTTP authentication handling and LDAP authorization
- Required access: Network access to a LibreNMS login endpoint; valid credentials may not be required
- Trigger point: Processing a user-supplied username during LDAP filter construction
- Why exploitation is possible: Unescaped LDAP metacharacters can alter the intended search filter, while existence-only authentication may treat a broad match as a valid user or group
- Attack surface: HTTP authentication handling and LDAP authorization
- Required access: Network access to a LibreNMS login endpoint; valid credentials may not be required
- Trigger point: Processing a user-supplied username during LDAP filter construction
- Why exploitation is possible: Unescaped LDAP metacharacters can alter the intended search filter, while existence-only authentication may treat a broad match as a valid user or group
Why this happens
The vulnerability results from concatenating untrusted usernames into LDAP search filters without applying context-appropriate LDAP escaping. Special filter characters can change the query's meaning, allowing attacker-controlled input to broaden or otherwise manipulate directory searches. This maps to CWE-90: Improper Neutralization of Special Elements used in an LDAP Query, compounded by an authentication design that does not sufficiently verify the identity and authorization of the matched account.
The vulnerability results from concatenating untrusted usernames into LDAP search filters without applying context-appropriate LDAP escaping. Special filter characters can change the query's meaning, allowing attacker-controlled input to broaden or otherwise manipulate directory searches. This maps to CWE-90: Improper Neutralization of Special Elements used in an LDAP Query, compounded by an authentication design that does not sufficiently verify the identity and authorization of the matched account.
Potential impact
- An unauthenticated attacker may bypass authentication
- An attacker could obtain administrative access to LibreNMS
- Directory-based authorization decisions may be manipulated
- Monitoring data, device configurations, and credentials may be exposed or altered
- A compromised administrative account could enable further attacks against monitored infrastructure
- An unauthenticated attacker may bypass authentication
- An attacker could obtain administrative access to LibreNMS
- Directory-based authorization decisions may be manipulated
- Monitoring data, device configurations, and credentials may be exposed or altered
- A compromised administrative account could enable further attacks against monitored infrastructure
General mitigation guidance
Mitigation generally focuses on treating all username and directory attributes as untrusted input and preserving a strict separation between data and LDAP query syntax.
Common defensive patterns include:
- Applying a well-tested LDAP filter-escaping routine to user-controlled values
- Building queries from fixed templates with narrowly constrained, validated identifiers
- Requiring explicit identity verification rather than accepting any directory entry that matches a search
- Enforcing server-side authorization checks after authentication
- Avoiding wildcard-compatible identity inputs and rejecting unexpected characters where appropriate
- Limiting administrative privileges granted through directory groups
- Restricting access to authentication endpoints and monitoring anomalous login or directory-query activity
Mitigation generally focuses on treating all username and directory attributes as untrusted input and preserving a strict separation between data and LDAP query syntax.
Common defensive patterns include:
- Applying a well-tested LDAP filter-escaping routine to user-controlled values
- Building queries from fixed templates with narrowly constrained, validated identifiers
- Requiring explicit identity verification rather than accepting any directory entry that matches a search
- Enforcing server-side authorization checks after authentication
- Avoiding wildcard-compatible identity inputs and rejecting unexpected characters where appropriate
- Limiting administrative privileges granted through directory groups
- Restricting access to authentication endpoints and monitoring anomalous login or directory-query activity
How teams detect issues like this
Organizations can look for:
- Static-analysis findings involving string concatenation or interpolation into LDAP filters
- Code review signals such as LDAP queries assembled from request headers without escaping
- Tests using LDAP metacharacters, wildcard values, empty values, and malformed identifiers
- Authentication flows that treat directory-record existence as sufficient proof of identity
- Web and directory logs showing repeated wildcard-like usernames or unusual authentication failures
- Policy enforcement requiring approved LDAP libraries and centralized escaping helpers
Automated code-review and security-scanning tools may help identify unsafe query construction, but behavioral testing and configuration review remain important.
Organizations can look for:
- Static-analysis findings involving string concatenation or interpolation into LDAP filters
- Code review signals such as LDAP queries assembled from request headers without escaping
- Tests using LDAP metacharacters, wildcard values, empty values, and malformed identifiers
- Authentication flows that treat directory-record existence as sufficient proof of identity
- Web and directory logs showing repeated wildcard-like usernames or unusual authentication failures
- Policy enforcement requiring approved LDAP libraries and centralized escaping helpers
Automated code-review and security-scanning tools may help identify unsafe query construction, but behavioral testing and configuration review remain important.
