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-115995Critical
A vulnerability was detected in Unitree Robotics Unitree Go2 up to version 1.1.11.4. The set_volume function in gpt_thread.py of the chat_go component mishandles the Value argument, leading to OS command injection. The attack can be launched remotely, and upgrading to version 1.1.11.5 resolves the issue.
- CVE-2026-114820Critical
Vulnerability in the JSSE component of Oracle Java SE, Oracle GraalVM for JDK, and Oracle GraalVM Enterprise Edition. It is easily exploitable by an unauthenticated attacker with network access, leading to unauthorized creation, deletion, or modification of critical data as well as unauthorized access to critical data. The vulnerability also applies to Java deployments that load and run untrusted code in a sandbox (e.g., Java Web Start applications or applets).
- CVE-2026-115933Critical
Postiz signs its session, invitation and password reset tokens with one shared secret and without any marker of what a token is for. A route that refreshes the credentials of a browser-extension channel signed data taken from the request itself and stored the result where the requesting user can read it back, allowing a user to obtain a validly signed token containing any claims they choose, accepted as a session, an organization invitation with a chosen role, a password reset or an enterprise provisioning token.
- CVE-2026-115557Critical
Python has added a denylist for known compromised certificates to the "ssl" module to ensure user safety even without certificate revocation configured. Known compromised certificates will automatically be rejected regardless of the SSLContext policy configuration.
- CVE-2026-115932Critical
In Postiz, a media path that is not a web address is treated as a file on the server's disk without verifying it lies inside the upload directory. A registered user can store a crafted media path with a post and cause the publishing worker to read an arbitrary file and send it as an attachment to a Discord server the user controls. The same unconfined reads are reachable through two further routes, including file existence checks and backend memory exhaustion; self-registration is open by default.
- CVE-2026-94075Critical
The WordPress plugin Newsletters (newsletters-lite) up to version 4.18.1 contains a deserialization of untrusted data vulnerability, allowing object injection. This could enable an attacker to execute unintended code.
- CVE-2026-114196Critical
The WordPress plugin Paytium up to version 5.0.5 is vulnerable to deserialization of untrusted data, allowing object injection. This may enable an attacker to perform unauthorized actions.
- CVE-2026-112866Critical
The WordPress plugin Product Filter by WBW (woo-product-filter) up to version 3.4.6 is vulnerable to blind SQL injection due to improper neutralization of special elements in SQL commands. An attacker could exploit this to manipulate database queries.
- CVE-2026-111402Critical
The WordPress plugin Newsletters (newsletters-lite) up to version 4.18.1 is vulnerable to SQL injection due to improper neutralization of special elements in SQL commands. This could allow an attacker to execute arbitrary SQL queries.
- CVE-2026-110956Critical
The asVereinbase WordPress plugin before version 1.1.8 does not require a valid password or a genuine second factor before authenticating a user, treating an empty stored value as a match. This allows an unauthenticated attacker to log in as any user, including an administrator.
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