CVE-2026-11748: Unauthenticated LDAP Injection in Central Dogma Server Authentication

An LDAP (Lightweight Directory Access Protocol) Injection vulnerability, tracked as CVE-2026-11748 and GHSA-98q5-5qh2-7w75, has been identified in Central Dogma, an open-source, highly available version-controlled service registry and configuration repository. Specifically, the flaw lies within the centraldogma-server-auth-shiro module, which handles external user authentication and directory lookups using Apache Shiro.

When configured to use Active Directory or LDAP for authentication, Central Dogma allows clients to authenticate through a web user interface or API endpoint. This exposure creates a direct attack surface where unauthenticated network-adjacent or public attackers can submit arbitrary input through authentication forms. The input is then integrated into critical LDAP query pipelines.

The vulnerability is classified under CWE-90 (Improper Neutralization of Special Elements used in an LDAP Query). By exploiting this flaw, attackers can manipulate the structural format of the generated LDAP query. This manipulation causes logical authentication confusion, directory enumeration, and administrative boundary bypasses without requiring valid initial credentials.

The root cause of the vulnerability lies in the implementation of the SearchFirstActiveDirectoryRealm.findUserDn() method. In standard Java LDAP implementations using JNDI (Java Naming and Directory Interface), there are no built-in parameterized query APIs analogous to JDBC PreparedStatement objects. Consequently, developers must manually format search filters, which introduces risks of injection when user-supplied parameters are handled incorrectly.

In vulnerable versions of Central Dogma, the system constructs LDAP search filters dynamically by calling a regular expression replacement on a predefined template. By default, the template is configured as cn={0}, where {0} acts as a placeholder for the username. The server executes this replacement directly on the unescaped username provided by the user in the login request.

Because the input contains no sanitization, special characters defined in RFC 4515, such as wildcards (*), parentheses ((, )), backslashes (\), and null bytes (\0), preserve their special meanings. When these characters are sent to the LDAP directory controller, they modify the logic of the filter itself rather than being treated as literal string values.

In vulnerable releases, the dynamic substitution was executed utilizing USERNAME_PLACEHOLDER.matcher(searchFilter).replaceAll(username). Because this method treats the username string literally during replacement, regex patterns and raw LDAP control characters are directly evaluated.

The patch introduced in version 0.84.0 replaces this logic entirely. Instead of executing unchecked replacements, the code now invokes a custom sanitization routine named encodeLdapFilter(String value). This routine parses the string character-by-character and translates all structural RFC 4515 characters to their equivalent safe ASCII hexadecimal values.

// Vulnerable Implementation (Before Patch)
final String filter =
        searchFilter != null ? USERNAME_PLACEHOLDER.matcher(searchFilter)
                                                   .replaceAll(username)
                             : username;
final NamingEnumeration<SearchResult> result = ctx.search(searchBase, filter, ctrl);
 
// Patched Implementation (After Patch in 0.84.0)
final String escaped = encodeLdapFilter(username);
final String filtered = searchFilter.replace(USERNAME_PLACEHOLDER, escaped);
final NamingEnumeration<SearchResult> result = ctx.search(searchBase, filtered, ctrl);

The encodeLdapFilter helper method iterates through the input and replaces control structures as shown below:

static String encodeLdapFilter(String value) {
    if (value == null) {
        return "";
    }
    final StringBuilder sb = new StringBuilder(value.length());
    for (int i = 0; i < value.length(); i++) {
        final char c = value.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();
} 

This implementation is highly effective and complete. By transforming character operations into hexadecimal escapes before passing the filter to ctx.search(), the LDAP server is forced to treat the characters as literals, neutralizing all injection paths.

Exploitation of this vulnerability requires network access to the Central Dogma authentication service. Since LDAP directory configurations vary, three distinct exploit vectors can be leveraged to compromise system security depending on the backend implementation.

The first vector is wildcard injection. By submitting a username of *, the resulting LDAP search filter becomes cn=*. Because the query limits results to one entry (ctrl.setCountLimit(1)), the directory server returns the first available record (typically the domain administrator). The Shiro framework then attempts to bind with the administrator's DN using the password provided by the attacker. If the backend LDAP allows unauthenticated binds or null password validation, this allows complete login bypass.

The second vector involves boolean injection. An attacker can construct a payload such as alice)(uid=* which alters the query sequence to cn=alice)(uid=*. This allows the attacker to break out of the configured attribute restriction and check other fields. The final vector is blind directory structure enumeration, where an attacker measures response times or error codes from structural queries to determine the names of valid groups and directory objects.

The impact of CVE-2026-11748 is classified as Medium, with a CVSS v4.0 base score of 6.9. Because Central Dogma often stores sensitive application configurations and deployment secrets, gaining access to the platform can lead to secondary compromises of connected systems.

If the LDAP server is configured to allow blank password binds, the attacker can log in as arbitrary administrative users. Even in configurations where passwords are validated, attackers can leverage timing side-channels and structural injection responses to enumerate valid corporate users, organizational units (OUs), and internal active directory structures.

Additionally, audit log evasion is a factor. Because the application logs the unescaped string submitted in the HTTP request, but the directory controller executes a completely different logical query due to parenthetical parsing, security tools monitoring active directory commands will show inconsistent execution contexts, complicating forensic investigations.

The primary resolution is to upgrade LY Corporation Central Dogma to version 0.84.0 or later. This release enforces full RFC 4515 escaping on all elements of LDAP search filters.

If an immediate upgrade is impossible, administrators can apply temporary mitigations at the network or directory level. Deploying custom Web Application Firewall (WAF) rules is highly recommended. Rules should detect and block common LDAP control characters in the username field of login endpoints, specifically targeting regex patterns matching .*[(\|&)=\*].*.

Furthermore, administrators should audit directory server settings to disable unauthenticated binds and restrict the service account used by Central Dogma to read-only access on specific, non-administrative organizational units. This limits the blast radius of any successful enumeration attempts.