int prefixLength = prefix != null ? prefix.length() : 0;
int suffixLength = suffix != null ? suffix.length() : 0;
StringBuilder sb = new StringBuilder(prefixLength + principal.length() + suffixLength);
if (prefixLength > 0) {
    sb.append(prefix);
}
sb.append(principal);            // <-- inserted verbatim
if (suffixLength > 0) {
    sb.append(suffix);
}
return sb.toString();

Шаблон разбивается один раз, во время конфигурации, вокруг токена `{0}`
(`setUserDnTemplate`, строки 181–200), на `prefix` и `suffix`. Во время аутентификации
principal конкатенируется между ними. **Кодирование не применяется ни на каком этапе.** Нигде
в `org/apache/shiro/realm/ldap/` нет вспомогательной функции экранирования.

### 3.2 Инвариант, который предполагался, но никогда не обеспечивался

Окружающий код рассматривает результат `getUserDn` как правильно сформированное Distinguished Name —
он передаётся напрямую в `LdapContextFactory.getLdapContext(...)` и оттуда в JNDI как
bind DN. Это корректно только в том случае, если подставляемый principal является *единственным значением атрибута*.

Конкатенация строк не может этого обеспечить. RFC 2253 (и RFC 4514) резервируют
`,` `+` `"` `\` `<` `>` `;` `=`, ведущий `#` и ведущие/замыкающие пробелы как структурный
синтаксис внутри DN. Когда любой из них появляется в principal, он читается парсером как
структура, а не как содержимое. Инвариант — *«principal занимает ровно одно значение RDN»* —
предполагался каждым нижестоящим потребителем и не обеспечивался никем.

### 3.3 Поток выполнения, от точки входа до дефекта```
  submitted credentials (username, password)
        │
        ▼
  DefaultLdapRealm.doGetAuthenticationInfo(AuthenticationToken)        [line 292]
        │
        ▼
  DefaultLdapRealm.getLdapPrincipal(AuthenticationToken)               [line 338]
        │   principal instanceof String ?
        │       ├── no  ──► return principal unchanged   ── NOT AFFECTED (e.g. X.509)
        │       └── yes ──┐
        ▼                 │
  DefaultLdapRealm.getUserDn(String)                                   [line 227]
        │   prefix == null && suffix == null ?
        │       ├── yes ──► return principal unchanged   ── NOT AFFECTED ("principal IS the DN")
        │       └── no  ──┐
        ▼                 │
  prefix + principal + suffix          ◄── DEFECT: unencoded concatenation  [line 246]
        │
        ▼
  LdapContextFactory.getLdapContext(userDn, credentials)
        │
        ▼
  JNDI bind against the directory using the constructed DN

Это **параметризованная** перегрузка `DirContext.search(String, String, Object[], SearchControls)`.
Имя пользователя передаётся как *аргумент* фильтра и никогда не конкатенируется в строку
фильтра. Согласно javadoc JDK 8 `javax.naming.directory.DirContext`, дословно:

> "When a string-valued filter argument is substituted for a variable, the filter is
> interpreted as if the string were given in place of the variable, with any characters
> having special significance within filters (such as `'*'`) having been escaped according
> to the rules of RFC 2254."

Экранирование выполняет JNDI-провайдер. Историческое свидетельство этого находится в самом
объявлении поля.

**Источник: `core/src/main/java/org/apache/shiro/realm/ldap/AbstractLdapRealm.java`, строки 88–89**```java
    //SHIRO-115 - prevent potential code injection:
    protected String searchFilter = "(&(objectClass=*)(userPrincipalName={0}))";

    SearchControls searchCtls = new SearchControls();
    searchCtls.setSearchScope(SearchControls.SUBTREE_SCOPE);

    String userPrincipalName = username;
    if (principalSuffix != null && !userPrincipalName.toLowerCase(Locale.ROOT).endsWith(principalSuffix.toLowerCase(Locale.ROOT))) {
        userPrincipalName += principalSuffix;
    }

    Object[] searchArguments = new Object[]{userPrincipalName};

    NamingEnumeration answer = ldapContext.search(searchBase, searchFilter, searchArguments, searchCtls);

Имя пользователя попадает в каталог как `searchArguments[0]`, а не как текст, вставленный в
`searchFilter`. Токен `{0}` в фильтре разрешается провайдером JNDI, а не
Shiro.

`ActiveDirectoryRealm` в строке 108 передаёт необработанное имя пользователя в
`getLdapContext(username, password)`. Это значение становится единственной записью окружения JNDI
`SECURITY_PRINCIPAL`; оно не подставляется в шаблон, и из него не конструируется DN,
поэтому оно находится вне механизма данного дефекта.

**Проверено эмпирически на работающем сервере каталога.** Экранирование JNDI не было принято
на веру: оно наблюдалось на уровне сетевого обмена. Внутрипроцессный LDAP-сервер
(UnboundID `InMemoryDirectoryServer`) был инструментирован с помощью
`InMemoryOperationInterceptor`, который записывает фильтр каждого получаемого поискового запроса,
и стандартный `searchFilter` Shiro был отправлен через тот же параметризованный вызов JNDI, который
использует `ActiveDirectoryRealm`, со специально сформированным аргументом:```
filter template : (&(objectClass=*)(userPrincipalName={0}))
argument passed : *)(uid=jsmith
server received : (&(objectClass=*)(userPrincipalName=\2a\29\28uid=jsmith))

Управление достигает сервера с изменённой структурой — добавлено третье условие, а
проверка `userPrincipalName` сведена к подстановочному знаку. Параметризованная форма — нет. Это
подтверждает, путём наблюдения, а не по контракту, что путь `searchFilter` не
затронут.

---

## 4. Пошаговые шаги воспроизведения

Детерминированно, из чистого checkout. Рабочий каталог на протяжении всего времени — корень репозитория.

### 4.1 Предварительные требования

| Требование | Используемое значение |
|---|---|
| JDK | **8** — ветка устанавливает `jdk.version` 1.8. Результаты ниже получены с Zulu 1.8.0_432 (arm64). Перед выполнением любой команды в этом разделе укажите `JAVA_HOME` на установку JDK 8: |
| Сборка | Apache Maven, требуется доступ к сети (родительский POM `org.apache:apache:38`) |
| Базовая версия | `origin/1.13.x` |
| Конфигурация | `userDnTemplate = uid={0},ou=users,dc=mycompany,dc=com` |
| Сервер каталогов | **Не требуется для §4.3-§4.4** — дефект находится в построении DN, до любого сетевого вызова, поэтому на этих шагах `LdapContextFactory` мокируется. §4.5 дополнительно воспроизводит весь путь против **реального** LDAP-сервера по HTTP. |

Установка `JAVA_HOME` на установку JDK 8:```bash
# macOS
export JAVA_HOME=$(/usr/libexec/java_home -v 1.8)

# Linux (path varies by distribution and vendor)
export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64

# Windows (cmd)
set JAVA_HOME=C:\Program Files\Zulu\zulu-8

### 4.3 Наблюдение дефекта напрямую

Это минимальный триггер, не зависящий от сборки Shiro. Запишите `Repro.java` во временный
каталог:```java
import javax.naming.ldap.LdapName;

public class Repro {
    // reproduces DefaultLdapRealm.getUserDn line-for-line
    static String getUserDn(String prefix, String principal, String suffix) {
        StringBuilder sb = new StringBuilder(prefix.length() + principal.length() + suffix.length());
        sb.append(prefix);
        sb.append(principal);
        sb.append(suffix);
        return sb.toString();
    }

    public static void main(String[] args) throws Exception {
        String prefix = "uid=";
        String suffix = ",ou=users,dc=mycompany,dc=com";

        String benign = getUserDn(prefix, "jsmith", suffix);
        System.out.println("benign : " + benign + "  -> RDNs=" + new LdapName(benign).size());

        String crafted = getUserDn(prefix, "jsmith,ou=admins", suffix);
        System.out.println("crafted: " + crafted + "  -> RDNs=" + new LdapName(crafted).size());
    }
}

Наблюдаемый вывод:```
benign : uid=jsmith,ou=users,dc=mycompany,dc=com  -> RDNs=4
crafted: uid=jsmith,ou=admins,ou=users,dc=mycompany,dc=com  -> RDNs=5

Сборка останавливается на `Apache Shiro :: Core` из-за провала проверочных тестов — полный захваченный вывод см. в §6.1:```
DefaultLdapRealmTest   Tests run: 16, Failures: 4, Errors: 0, Skipped: 0
JndiLdapRealmTest      Tests run: 16, Failures: 4, Errors: 0, Skipped: 0

#### 4.5.1 Затронутая сборка

**Запрос**```http
POST /login HTTP/1.1
Host: 127.0.0.1
Content-Type: application/x-www-form-urlencoded

username=jsmith%2Cou%3Dadmins&password=adminpass

**Bind DN, полученный каталогом**```
uid=jsmith,ou=admins,ou=users,dc=mycompany,dc=com

| `--no-color` | Отключить цветной вывод |
| `--debug` | Включить отладочный вывод |
| `--verbose` | Включить подробный вывод |
| `--silent` | Подавить весь вывод, кроме ошибок |
| `--json` | Выводить результаты в формате JSON |
| `--csv` | Выводить результаты в формате CSV |
| `--output <file>` | Записать вывод в файл |
| `--config <file>` | Использовать указанный файл конфигурации |
| `--timeout <seconds>` | Установить тайм-аут для операций |
| `--retry <count>` | Количество повторных попыток при неудачных операциях |
| `--threads <count>` | Количество потоков для использования |
| `--rate-limit <rps>` | Ограничить количество запросов в секунду |
| `--proxy <url>` | Использовать указанный прокси-сервер |
| `--user-agent <string>` | Установить строку User-Agent |
| `--header <header>` | Добавить пользовательский заголовок |
| `--cookie <cookie>` | Добавить пользовательский cookie |
| `--follow-redirects` | Следовать перенаправлениям HTTP |
| `--insecure` | Игнорировать ошибки сертификата SSL |
| `--version` | Показать информацию о версии |
| `--help` | Показать справочное сообщение |```http
HTTP/1.1 200 OK

Обычные логины не изменяются — строка 1 аутентифицируется одинаково в обеих сборках, при этом
каталог получает `uid=jsmith,ou=users,dc=mycompany,dc=com`.

Оба запуска использовали один и тот же harness и одну и ту же фикстуру; различался только
`shiro-core` в classpath. Фактически загруженный класс был подтверждён с помощью `-verbose:class` для каждого запуска.

---

## 5. Детали исправления и код исправления

### 5.1 Основное исправление

Кодируйте principal как значение одного атрибута DN перед подстановкой, используя собственный
кодировщик JDK, соответствующий RFC 2253, `javax.naming.ldap.Rdn.escapeValue`. Это тот же механизм,
который JDK использует для построения имён, поэтому его вывод по построению согласован с парсером,
который его потребляет.

**Файл:** `core/src/main/java/org/apache/shiro/realm/ldap/DefaultLdapRealm.java````diff
@@ -35,6 +35,7 @@ import org.slf4j.LoggerFactory;
 import javax.naming.AuthenticationNotSupportedException;
 import javax.naming.NamingException;
 import javax.naming.ldap.LdapContext;
+import javax.naming.ldap.Rdn;
 
 /**
  * An LDAP {@link org.apache.shiro.realm.Realm Realm} implementation utilizing Sun's/Oracle's
@@ -239,11 +240,14 @@ public class DefaultLdapRealm extends AuthorizingRealm {
 
         int prefixLength = prefix != null ? prefix.length() : 0;
         int suffixLength = suffix != null ? suffix.length() : 0;
-        StringBuilder sb = new StringBuilder(prefixLength + principal.length() + suffixLength);
+        //the principal is a single attribute value within the resulting name, so it is encoded
+        //to keep any characters that are significant in a Distinguished Name within that value:
+        String value = Rdn.escapeValue(principal);
+        StringBuilder sb = new StringBuilder(prefixLength + value.length() + suffixLength);
         if (prefixLength > 0) {
             sb.append(prefix);
         }
-        sb.append(principal);
+        sb.append(value);
         if (suffixLength > 0) {
             sb.append(suffix);
         }

Захваченный вывод сбоя — это доказательство, и его невозможно восстановить после применения исправления:```
testGetUserDnPreservesTemplateStructure:238
  User DN gained or lost components relative to the template:
  uid=jsmith,ou=admins,ou=users,dc=mycompany,dc=com
  expected:<4> but was:<5>

testGetUserDnPreservesTemplateStructureForReservedCharacters:262
  Component count changed for principal [jsmith,ou=admins]:
  uid=jsmith,ou=admins,ou=users,dc=mycompany,dc=com
  expected:<4> but was:<5>

testGetUserDnEncodesSubstitutedValue:280
  expected:<uid=jsmith[\,ou\]=admins,ou=users,dc=...>
   but was:<uid=jsmith[,ou]=admins,ou=users,dc=...>

testUserDnTemplateSubstitutionPreservesStructure:300
  Unexpected method call
    LdapContextFactory.getLdapContext("uid=jsmith,ou=admins,ou=users,dc=mycompany,dc=com", ...)
  expected:
    LdapContextFactory.getLdapContext("uid=jsmith\,ou\=admins,ou=users,dc=mycompany,dc=com", ...)
    expected: 1, actual: 0

Все четыре проверочных теста теперь проходят для обоих классов. Повторный запуск §4.3 с внесённым исправлением
даёт `RDNs=4` для сконструированного principal.

### 6.3 Добавленные тесты

**Файл:** `core/src/test/java/org/apache/shiro/realm/ldap/DefaultLdapRealmTest.java`
(+124 строки, 0 удалений). Поскольку `JndiLdapRealmTest extends DefaultLdapRealmTest`, каждый
тест ниже выполняется против **обоих** realm — 10 выполнений из 5 методов.

| Тест | Проверяет | Базовый результат |
|---|---|---|
| `testGetUserDnLeavesOrdinaryPrincipalUnchanged` | Обычный principal даёт точно ожидаемый DN, 4 RDN, значение не изменено. Защищает от избыточного экранирования. | **пройден** (защитный) |
| `testGetUserDnPreservesTemplateStructure` | Для `jsmith,ou=admins` DN по-прежнему содержит 4 компонента, а principal сохраняется как одно значение атрибута. | не пройден |
| `testGetUserDnPreservesTemplateStructureForReservedCharacters` | То же самое для всех 10 principal с зарезервированными символами; также завершает тест неудачей, если DN не является корректно сформированным именем. | не пройден |
| `testGetUserDnEncodesSubstitutedValue` | Подставленное значение закодировано так, что при обратном преобразовании получается исходный principal. | не пройден |
| `testUserDnTemplateSubstitutionPreservesStructure` | Сквозная проверка через `getAuthenticationInfo`: DN, передаваемый в `LdapContextFactory`, сохраняет структуру шаблона. | не пройден |

**Замечание по проектированию.** Структурные проверки разбирают результат с помощью `javax.naming.ldap.LdapName`
и сравнивают количество компонентов и значение листа после обратного преобразования,
а не проверяют ожидаемую экранированную строку. Таким образом, тесты проверяют фактически требуемое свойство и не
предполагают `Rdn.escapeValue` в качестве реализации — альтернативный корректный кодировщик
также прошёл бы проверку.

Команда:```bash
mvn -B clean verify

**СБОРКА УСПЕШНА — 907 тестов, 0 сбоев, 0 ошибок, 3 пропущено, по всему реактору.**
В этом запуске активны все проверки: модульные тесты (surefire), интеграционные тесты (failsafe),
аудит лицензий Apache RAT, maven-enforcer и japicmp.

| Проверка | Результат |
|---|---|
| Модульные тесты, весь реактор | **907 запущено, 0 сбоев, 0 ошибок, 3 пропущено** |
| Только модуль `core` | **321 запущено, 0 сбоев, 0 ошибок, 0 пропущено** |
| Тесты LDAP (`DefaultLdapRealmTest` + `JndiLdapRealmTest`) | **32 запущено, 0 сбоев** |
| Интеграционные тесты (failsafe) | выполнены по всему реактору, сбоев нет |
| Аудит лицензий Apache RAT | Не одобрено: 0, неизвестно: 0 |
| maven-enforcer | нарушений нет |
| japicmp | несовместимостей не обнаружено |

3 пропуска — это существовавшие ранее `@Ignore` в модулях, не связанных с этим изменением; `core` —
единственный затронутый модуль — ничего не пропускает.

## Ссылки

- Запись CVE (MITRE API): `https://cveawg.mitre.org/api/cve/CVE-2026-49268`
- Объявление upstream: `https://lists.apache.org/thread/svszql3od8td7hn6conyj2oq70v53b5s`
- Отчёты о безопасности Apache Shiro: `https://shiro.apache.org/security-reports.html`
- RFC 2253 / RFC 4514 — строковое представление Distinguished Names в LDAP
- RFC 4515 — строковое представление фильтра поиска LDAP

## Контакты

Автор исследования и устранения уязвимостей безопасности: Jinwoo Hwang ([https://JinwooHwang.com](https://jinwoohwang.com/))