Threats Tagged 'cwe-90'

A vulnerability was identified in Eleveo Call Recording Software 9.7.0. This vulnerability affects unknown code of the file /callrec/userAddAction.do of the component User Management. Such manipulation of the argument Username leads to ldap injection. The attack can be executed remotely. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way.

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.

GLPI is a free asset and IT management software package. From 0.70 until 10.0.26 and 11.0.8, an authenticated hotliner or technician can submit crafted criteria through the user import feature to bypass the configured default LDAP filter. This allows access to LDAP objects that the default filter was intended to exclude. This issue is fixed in versions 11.0.8 and 10.0.26.

RabbitMQ is a messaging and streaming broker. The advisory establishes affected 3.13, 4.0, 4.1, 4.2, and 4.3 maintenance lines but contains conflicting first-fixed versions for the 3.13, 4.0, and 4.1 lines. fill/2 substitutes ${username} into user_dn_pattern without RFC 4514 DN escaping, allowing a crafted username to alter the LDAP bind DN and potentially select a different directory entry. Exploitation requires rabbitmq_auth_backend_ldap with a user_dn_pattern containing ${username}, a directory layout in which the injected suffix resolves usefully, and a password valid for the resulting DN. The advisory body identifies 3.13.15, 4.0.20, 4.1.11, 4.2.9, and 4.3.3 as fixed, while structured metadata identifies 3.13.18, 4.0.23, 4.1.14, 4.2.9, and 4.3.3. No fixed-version assertion is certifiable until a curator resolves this conflict.

Fabric CA versions prior to 1.5.21, when configured with an LDAP backend, are vulnerable to LDAP injection due to unescaped usernames in the LDAP UserFilter during authentication. This allows an unauthenticated attacker with network access to manipulate LDAP searches before password validation, potentially redirecting authentication attempts to victim accounts. Deployments not using LDAP backends are not affected. The issue is fixed in version 1.5.21.

Open Access Management (OpenAM) versions prior to 16.1.1 contain a vulnerability in the MSISDN authentication module where unsanitized user input is concatenated into an LDAP search filter. This allows an unauthenticated remote attacker to inject LDAP filter metacharacters, select an arbitrary user, and obtain an authenticated session without a password. The issue is fixed in version 16.1.1.

Open Access Management (OpenAM) is an access management solution. Prior to 16.1.1, IdentityResourceV1.queryCollection() passes the _queryId parameter from /json/{realm}/users to CrestQuery with escapeQueryId disabled, bypassing protection added for CVE-2021-29156. The unescaped value reaches DJLDAPv3Repo.getFilter(), where it is concatenated into an LDAP filter, allowing an authenticated attacker to inject LDAP metacharacters for user enumeration and blind LDAP injection. This issue is fixed in version 16.1.1.

# Vulnerability `SearchFirstActiveDirectoryRealm.findUserDn()` substitutes the user-supplied username from the login form into an LDAP search filter template (default `cn={0}`) **without escaping RFC 4515 filter metacharacters** (`*`, `(`, `)`, `\`, NUL). Combined with `SearchControls.setCountLimit(1)` on the same call site, this allows three distinct attack primitives: 1. **Authentication confusion** — typing username `*` causes the realm to construct filter `cn=*`, return the first directory entry (typically a privileged account in AD ordering), and attempt bind against that DN with the attacker's password. 2. **Audit log evasion** — payload `bob)(uid=alice` is recorded verbatim in audit logs while the realm searches with the malformed filter, breaking accountability/compliance (SOX, PCI-DSS, ISO 27001). 3. **Directory enumeration** — wildcards and timing differences allow reconnaissance of OU structure and admin group membership. A repo-wide search for any LDAP escape helper (`escapeLdap`, `encodeFilter`, `escapeFilter`, `ldapEscape`) returns **zero hits** — the defense is not just missing, it was never added. > **Applicability note:** This realm is opt-in. The shipped default LDAP example (`dist/src/conf/shiro.example.ldap.ini`) uses Shiro's `DefaultLdapRealm` with `userDnTemplate` and is **NOT** affected. However, the realm exists precisely to support Active Directory environments where users log in via `sAMAccountName` and the realm must search for the DN first — the canonical LINE corporate AD-backed SSO scenario. Internal deployments using AD-backed login almost certainly select this realm. --- ## Evidence **File:** `server-auth/shiro/src/main/java/com/linecorp/centraldogma/server/auth/shiro/realm/SearchFirstActiveDirectoryRealm.java` **Lines 148–176** on branch `main` @ commit `d64a5151`: ```java @Nullable protected String findUserDn(LdapContextFactory ldapContextFactory, String username) throws NamingException { LdapContext ctx = null; try { ctx = ldapContextFactory.getSystemLdapContext(); final SearchControls ctrl = new SearchControls(); ctrl.setCountLimit(1); // line 156 — returns FIRST match only ctrl.setSearchScope(SearchControls.SUBTREE_SCOPE); ctrl.setTimeLimit(searchTimeoutMillis); final String filter = searchFilter != null ? USERNAME_PLACEHOLDER.matcher(searchFilter) .replaceAll(username) // line 162 — RAW SUBSTITUTION : username; // line 163 final NamingEnumeration result = ctx.search(searchBase, filter, ctrl); ... ``` `USERNAME_PLACEHOLDER = Pattern.compile("\\{0}")`. Default `searchFilter = "cn={0}"`. ### Data flow from HTTP login to vulnerable substitution | Step | Component | |------|-----------| | HTTP login form | `POST /api/v1/login` form field `username` | | `ShiroLoginService.usernamePassword()` (lines 198–223) | applies `loginNameNormalizer` (Unicode lowercase only — **NOT** LDAP escape) | | `Subject.login(new UsernamePasswordToken(username, password))` | Shiro hand-off | | `ActiveDirectoryRealm.doGetAuthenticationInfo` (Shiro core) | calls `queryForAuthenticationInfo0` | | `SearchFirstActiveDirectoryRealm.findUserDn(factory, upToken.getUsername())` | username flows in **verbatim** | ### Repository-wide escape helper grep | Search term | Hits | |-------------|------| | `escapeLdap` | 0 | | `encodeFilter` | 0 | | `escapeFilter` | 0 | | `ldapEscape` | 0 | --- ## PoC Self-contained JUnit 5 test using UnboundID `InMemoryDirectoryServer` (in-process, no external LDAP required). Drop into `server-auth/shiro/src/test/java/com/linecorp/centraldogma/server/auth/shiro/realm/LdapInjectionPoCTest.java` and add `com.unboundid:unboundid-ldapsdk:7.0.0` as a test dependency. > The PoC works by subclassing the realm and overriding `findUserDn()` to capture the actual LDAP filter string sent to the directory — the captured filter is the structural evidence, independent of LDAP server strictness about bind outcomes. ```java /* * Copyright 2026 LINE Corporation * * SECURITY PoC — NOT FOR MERGE INTO THE MAIN TEST SUITE. * * This JUnit class demonstrates the LDAP filter injection in * SearchFirstActiveDirectoryRealm. Drop into * server-auth/shiro/src/test/java/com/linecorp/centraldogma/server/auth/shiro/realm/ * Adds the UnboundID LDAP SDK as a test dep. */ package com.linecorp.centraldogma.server.auth.shiro.realm; import static org.assertj.core.api.Assertions.assertThat; import static org.assertj.core.api.Assertions.assertThatThrownBy; import javax.naming.directory.SearchControls; import javax.naming.ldap.LdapContext; import org.apache.shiro.realm.ldap.JndiLdapContextFactory; import org.apache.shiro.realm.ldap.LdapContextFactory; import org.junit.jupiter.api.AfterAll; import org.junit.jupiter.api.BeforeAll;

Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection') vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to script injection.

Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection') vulnerability in Drupal LDAP / Active Directory Integration allows LDAP Injection. This issue affects LDAP / Active Directory Integration versions: from 0.0.0 to 2.2.1.