CVE-2026-90979
HighCVSS 7.3Exploitation Probability (EPSS)
Low risk36th percentile - higher than 36% of all known CVEs
Summary
LDAPCache and LDAPBackingEngine build LDAP search filters by substituting %u, %dn, and %fqdn into administrator-configured filter templates (userFilter, roleFilter) without full RFC 4515 escaping. Before the fix, only double backslashing was applied, which does not escape *, (, ), and NUL. A login name containing these characters can alter the filter structure, e.g. turning an equality match into a wildcard match or closing/reopening filter clauses.
Risk Assessment
The vulnerability can cause a login or role lookup to match an LDAP entry other than the intended one, over-granting roles, or potentially affecting which account a login resolves to. It is not exploitable through every entry point — LDAPLoginModule and LDAPPubkeyLoginModule escape the login name, but GSSAPILdapLoginModule and LDAPBackingEngine (listRoles) pass it through unescaped.
Recommendation
Apply the vendor fix that introduces full RFC 4515 escaping (*, (, ), NUL) in LDAPCache and LDAPBackingEngine. Until the fix is deployed, restrict the ability to create login names containing these characters and review the userFilter and roleFilter templates.
Related vulnerabilities
- CVE-2026-117691Critical
A flaw was found in the SAML HTTP-Redirect binding implementation of Keycloak. The issue occurs because the server processes percent-encoded parameter names (like %53AMLResponse) while the signature verification logic only checks literal parameter names. An attacker can use this discrepancy to provide a crafted, unsigned SAML message that the server processes instead of a legitimately signed one, leading to full account takeover of federated users.
- CVE-2026-96677Critical
Cross-site Scripting (XSS) vulnerability in Apache Juneau. HTML document serialization does not HTML-encode variable substitutions in page chrome fields (header, nav, footer, etc.), so applications that place request-derived values there reflect them unencoded.
- CVE-2026-73117Critical
HTTP Response Splitting (CRLF injection in HTTP headers) vulnerability in Apache Juneau. The REST server passed response header values and redirect targets to the servlet container unchecked, so request-derived data could allow header injection or redirect to an arbitrary site.
- CVE-2026-73116Critical
Insufficiently Protected Credentials vulnerability in Apache Juneau. The RestClient followed HTTP redirects while keeping credential headers from the original request, so a server redirecting to a different host, port, or from HTTPS to HTTP could receive Authorization, Cookie, Proxy-Authorization and X-API-Key headers.
- CVE-2026-73101Critical
Generation of Error Message Containing Sensitive Information vulnerability in Apache Juneau. The REST server sends the internal exception class and message to clients in a "Thrown" response header on every error response and may include internal exception messages in the error body, even with stack-trace rendering disabled.
- CVE-2026-73100Critical
Insertion of Sensitive Information into Log File vulnerability in Apache Juneau. The default REST server call logger records request headers for requests ending in a server error without redaction, so Authorization, Cookie, Proxy-Authorization and X-API-Key headers are written in cleartext to the application log.
- CVE-2026-73099Critical
Cross-Site Request Forgery (CSRF) vulnerability in Apache Juneau. The REST server accepts a "content" query parameter that replaces the request body and is enabled by default on every HTTP method including GET, so a cross-site link can deliver an attacker-chosen request body without a CORS preflight.
- CVE-2026-73098Critical
Improper control of dynamically-loaded code vulnerability in Apache Juneau. When parsing a value into a property of type java.lang.Class, the default class swap loaded the named class with initialization enabled, so input naming a class on the application classpath ran that class's static initializer.
- CVE-2026-121489Critical
Path Traversal vulnerability in Apache Juneau. The microservice DirectoryResource does not keep request paths inside its configured root directory; when an application enables the resource's view, upload or delete settings (all off by default), a client can read, write or delete files outside the root.
- CVE-2026-100109Critical
The Security For WooCommerce WordPress plugin from 1.0.10 to 1.0.16 does not perform capability checks when creating users through an action available to unauthenticated visitors, and lets the caller choose the new account's role. This allows unauthenticated attackers to create administrator accounts and take over the site.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

