The subject is excessively long; the prefix 'https://karaf.apache.org/security/cve-2026-90979.txt:' should be dropped in future announce emails
Thanks On Mon, 28 Sept 2026 at 10:31, Jean-Baptiste Onofré <[email protected]> wrote: > > Severity: moderate > > Affected versions: > > - Apache Karaf (org.apache.karaf.jaas.modules.ldap) before 4.4.12 > > Description: > > LDAPCache and LDAPBackingEngine build LDAP search filters for user lookup and > role lookup by textually substituting the placeholders %u, %dn, and %fqdn > (drawn from the login name, the resolved user DN, and its fully qualified > namespace form) into administrator-configured filter templates (userFilter, > roleFilter). Before the fix, the only sanitization applied to the substituted > value was double backslashed: > > filter = filter.replaceAll(Pattern.quote("%u"), > Matcher.quoteReplacement(user)); > > filter = filter.replace("\\", "\\\\"); > > > > > This does not escape the other characters RFC 4515 requires escaping in an > LDAP search filter: *, (, ), and NUL. A login name containing any of these > can change the structure of the resulting filter rather than being matched as > a literal value (e.g. a crafted username can turn an equality match into a > wildcard match, or close/reopen filter clauses), widening what the search > returns and potentially causing a login or role lookup to match an LDAP entry > other than the intended one, over-granting roles, and depending on > deployment-specific filter templates, potentially affecting which account a > login resolved to. > > > > > It's not exploitable through every entry points: LDAPLoginModule and > LDAPPubkeyLoginModule both called Util.doRFC2254Encoding() (correct RFC 4515 > escaping) on the login name before handing it to LDAPCache, which masked the > missing escaping in LDAPCache for those two call paths. Using LDAPCache > directly (bypassing the login modules) does not reproduce through the normal > LDAPLoginModule/LDAPPubkeyLoginModule authentication flow for this reason. It > does reproduce through two other call paths that reach > LDAPCache/LDAPBackingEngine without any prior escaping: > > * GSSAPILdapLoginModule passes the NameCallback name straight through, > unescaped. > * LDAPBackingEngine (listRoles) passes principal.getName() straight > through, unescaped. > > This issue is being tracked as https://github.com/apache/karaf/pull/2880 > > Credit: > > Gjoko Krstic <[email protected]> (reporter) > > References: > > https://karaf.apache.org/ > https://www.cve.org/CVERecord?id=CVE-2026-90979 > https://issues.apache.org/jira/browse/https://github.com/apache/karaf/pull/2880 >
