Skip to content
Fencer Intel
high 7.3

CVE-2026-90979 json

Apache Karaf: LDAP filter injection in JAAS LDAP login modules

published last mo. modified last mo. also EUVD-2026-88197

cvss
7.3
version 3.1, CNA
cisa kev
Not listed
not in CISA's catalog
epss
0.4%
EPSS 0.4% chance of exploitation in 30 days, percentile 38%
public exploits
0
none known

Summary

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.

Patch / fix

  • Apache Software Foundation Apache Karaf 4.4.12

Is CVE-2026-90979 in your stack? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2026-90979 updated cvss 6.8

karaf: org.apache.karaf.jaas/org.apache.karaf.jaas.modules: Apache Karaf: Privilege escalation via LDAP filter injection

  • Red Hat Fuse 7 org.apache.karaf.jaas.modules 4.2.15.fuse-7_11_1-00017-redhat-00001
    affected: no fix planned “Out of support scope”

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

CISA SSVC

Exploitation
none
Automatable
yes
Technical impact
partial
Assessed
last mo.

Exploit prediction

0.44% chance of exploitation in the next 30 days, higher than 38% of all scored CVEs (FIRST EPSS, 2026-11-11).

CVSS scores

assigned by version score vector
CISA ADP 3.1 7.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
CNA 3.1 7.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L

Affected products

  • Apache Software Foundation Apache Karaf

Classification

Weakness
  • CWE-90 Improper Neutralization of Special Elements used in an LDAP Query

References

Sources

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.

CPEs and fixed versions use Anchore's correction of NVD's data: Added CPE configurations because not yet analyzed by NVD.