sassoftware/shiroCVE-2026-49268 — Анализ и устранение уязвимости обхода аутентификации через LDAP-инъекцию
| Ветка | 1.13-CVE-2026-49268 |
| Автор | Jinwoo Hwang (https://JinwooHwang.com) |
Эта ветка (1.13-CVE-2026-49268) содержит комплексное устранение уязвимости обхода аутентификации через LDAP-инъекцию в релизе Apache Shiro 1.13.
Официальное описание NVD
Удалённый атакующий может внедрить специальные символы LDAP в конструкцию Distinguished Name (DN) в классе DefaultLdapRealm. Вводимое пользователем имя пользователя напрямую конкатенируется в шаблон LDAP DN без какого-либо экранирования специальных символов RFC 2253. Это позволяет атакующему манипулировать структурой DN, используемой для аутентификации через LDAP bind, потенциально обходя аутентификацию или выдавая себя за других пользователей. Эта проблема затрагивает все версии Apache Shiro вплоть до 2.2.0 и 3.0.0-alpha-1 при использовании DefaultLdapRealm.
| Поле | Значение |
|---|---|
| CVE | CVE-2026-49268 — Apache Shiro: LDAP DN Injection в DefaultLdapRealm |
| CWE ID | CWE-90 — Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection') |
| CVSS v4.0 | 8.8 HIGH — CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N/S:P/AU:Y/R:A/RE:L/U:Red |
| CVSS v3.1 | 9.1 CRITICAL — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N |
| Затронутые версии | org.apache.shiro:shiro-core от 0 до 2.2.0 включительно; от 3.0.0-alpha-0 до 3.0.0-alpha-1 включительно |
| Исправлено в upstream | 2.2.1 и 3.0.0-alpha-2 |
| Ссылка | https://lists.apache.org/thread/svszql3od8td7hn6conyj2oq70v53b5s |
Apache Shiro может аутентифицировать пользователей в каталоге LDAP. Для этого он преобразует
переданное имя пользователя в Distinguished Name — адрес записи этого пользователя в каталоге —
путём подстановки имени пользователя в настроенный шаблон, например
uid={0},ou=users,dc=mycompany,dc=com.
В затронутых версиях имя пользователя вставляется в этот шаблон как обычный текст. Несколько знаков пунктуации — в первую очередь запятая — не являются для сервера каталога обычным текстом; это синтаксис, разделяющий одну часть адреса от следующей. Поэтому имя пользователя, содержащее такие символы, перестаёт вести себя как значение внутри адреса и начинает вести себя как часть самого адреса.
Практическое следствие состоит в том, что входящий в систему человек может влиять на то, против какой записи каталога Shiro попытается аутентифицироваться, а не только предоставлять собственное имя. Вместо поиска в контейнере, предусмотренном развёртыванием, поиск может быть перенаправлен в другое место каталога. В зависимости от структуры каталога и его разрешений это может привести к аутентификации под чужой учётной записью или к успешной аутентификации там, где её быть не должно.
Профиль риска. Что повышает риск: не требуется предварительный доступ или учётные данные —
ввод поступает на границе входа в систему, доступной любому, кто может достичь
приложения; и затронутый класс является стандартным, документированным способом подключения Shiro к LDAP,
так что это не экзотическая конфигурация. Что понижает его: развёртывание должно действительно использовать
DefaultLdapRealm (или JndiLdapRealm) с настроенным шаблоном DN; развёртывания, которые
аутентифицируются другими способами или передают полный DN либо нетекстовые учётные данные, такие как
сертификат, не затронуты. То, даст ли перенаправленный поиск пригодную для использования аутентификацию,
также зависит от собственной структуры целевого каталога и правил доступа, которые различаются от сайта к сайту.
Стоит отметить и второе, не связанное с безопасностью последствие для планирования релиза: пользователи, чьи
легитимные имена пользователя содержат обратную косую черту или начинаются с #, в настоящее время вообще не могут войти в систему,
поскольку построенный для них адрес не является корректно сформированным именем и отвергается
сразу. Другая пунктуация не приводит к немедленному отказу — она молча меняет то, на какую запись
указывает адрес, что и является описанной выше проблемой безопасности. Одно и то же исправление решает обе.
core/src/main/java/org/apache/shiro/realm/ldap/DefaultLdapRealm.java, getUserDn(String),
строки 227–250 в неисправленной базовой версии:```java
protected String getUserDn(String principal) throws IllegalArgumentException, IllegalStateException {
if (!StringUtils.hasText(principal)) {
throw new IllegalArgumentException("User principal cannot be null or empty for User DN construction.");
}
String prefix = getUserDnPrefix();
String suffix = getUserDnSuffix();
if (prefix == null && suffix == null) {
log.debug("userDnTemplate property has not been configured, indicating the submitted "
+ "AuthenticationToken's principal is the same as the User DN. Returning the method argument "
+ "as is.");
return principal;
}
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»* —
предполагался каждым нижестоящим потребителем и не обеспечивался никем.