CVE-2026-95811: Lemonldap::NG::Handler versions from 2.0.0 before 2.16.10, from 2.17.0 before 2.21.6, from 2.22.0 before 2.23.4 for Perl allow an equivalent spelling of a path to bypass the locationRules that restrict it
Lemonldap::NG::Handler versions from 2.0.0 before 2.16.10, from 2.17.0 before 2.21.6, from 2.22.0 before 2.23.4 for Perl allow an equivalent spelling of a path to bypass the locationRules that restrict it.
The handler matches each vhost's locationRules regular expressions against REQUESTURI, the raw request line, while the web server routes on the path it has already percent-decoded and normalized. A request that percent-encodes a character of the path, inserts dot segments, or doubles a slash therefore reaches the protected resource under a URI that no rule regexp matches, and the vhost's default rule decides access. Deny rules, identity and group conditions, and unprotect and skip rules are bypassed alike.
Only a vhost whose default rule is more permissive than its other rules is affected. An authenticated user then reaches any URL a locationRules regexp was meant to restrict, but gains no more than that default rule already grants.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Lemonldap::NG::Handlerto a version that resolves this vulnerability.Fixed in 2.23.4
Event History
Frequently Asked Questions
Which deployments are actually affected?
Only vhosts whose default rule is more permissive than one or more locationRules are affected. Vhosts with a default rule that is equally or more restrictive than their location-specific rules are not exposed to this bypass.
What does an attacker need to exploit this issue?
The attacker needs to be an authenticated user and must request a protected URL using an equivalent path spelling that the web server normalizes but the locationRules regular expression does not match. Examples include percent-encoding a path character, adding dot segments, or using doubled slashes.
What access can be gained through the bypass?
An attacker can reach URLs that locationRules were intended to restrict, including rules based on denial, identity, group membership, unprotect, or skip conditions. The attacker does not gain permissions beyond what the vhost's default rule already allows.
What can be done if updating is not immediately possible?
Review each vhost for locationRules that are stricter than its default rule, and make the default rule at least as restrictive as the protected locations. This removes the permissive fallback that makes unmatched equivalent path spellings exploitable.
Which versions contain fixes?
The fixed releases are 2.16.10, 2.21.6, and 2.23.4. Affected versions are 2.0.0 through before 2.16.10, 2.17.0 through before 2.21.6, and 2.22.0 through before 2.23.4.