CVE-2026-86345 в Ubuntu: подмена ответа LDAP при StartTLS в 389-ds-base

CVE: CVE-2026-86345
Продукт: Ubuntu
Дата публикации: 02.10.2026
Критичность: CRITICAL
CVSS: 9.0 (3.1)
EPSS: 0,38%; процентиль 29,89%
CISA KEV: нет подтверждения в каталоге CISA KEV

Краткое описание​

В пакете 389-ds-base (389 Directory Server) в Ubuntu обнаружена ошибка обработки границы между открытым текстом и защищённым каналом. Сервер не отбрасывает уже буферизованные открытые байты клиентского соединения при согласовании StartTLS.

Атакующий на сетевом пути может внедрить сформированное LDAP-сообщение, которое будет обработано после перехода на TLS. Из-за коллизии messageID его ответ доставляется клиенту вместо ответа на его собственную ожидающую операцию.

В результате клиентское приложение может принять неудачную попытку аутентификации (bind) за успешную. Ошибка классифицирована как CWE-923. Red Hat присвоил CVSS 3.1 балл 9.0 (CRITICAL), Ubuntu оценивает severity как medium.

Основные характеристики​

Суть риска: атакующий в сетевом пути между LDAP-клиентом и сервером 389 Directory Server может внедрить LDAP-сообщение в момент согласования StartTLS. Клиент получит ответ на чужую операцию вместо ответа на свою — вплоть до того, что неудачный bind будет выглядеть как успешная аутентификация.

Ключевые параметры:

• Затронутый компонент — 389-ds-base (389 Directory Server) в Ubuntu; затронуты ветки 16.04, 18.04, 20.04 (Pro/ESM), 22.04, 24.04 и 26.04 LTS.
  
• Тип ошибки — CWE-923: некорректное ограничение связи/имперсонации; нарушается граница доверия между открытым и зашифрованным этапом соединения.
  
• CVSS 3.1 — CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H, балл 9.0 (CRITICAL) по оценке Red Hat; Ubuntu присваивает severity medium.
  
• EPSS — 0,382% (процентиль 29,89%): прогнозируемая вероятность эксплуатации в течение 30 дней низкая.
  
• CISA KEV — в каталоге Known Exploited Vulnerabilities уязвимость не значится; подтверждений эксплуатации в реальных атаках в доступных источниках нет.
  

Какие продукты и версии затронуты​

Затронутый компонент — сервер каталогов 389 Directory Server (исходный пакет 389-ds-base) в Ubuntu. По данным Ubuntu OSV, во всех перечисленных ветках указано introduced: 0, то есть уязвимость присутствует с начала истории пакета.

Затронутые релизы и версии пакетов:

• Ubuntu Pro 16.04 LTS (xenial, ESM) — 389-ds-base 1.3.4.9-1ubuntu0.1~esm1; бинарные пакеты 389-ds, 389-ds-base, 389-ds-base-libs.
  
• Ubuntu Pro 18.04 LTS (bionic, ESM) — 1.3.7.10-1ubuntu1+esm1; дополнительно python3-dirsrvtests, python3-lib389.
  
• Ubuntu Pro 20.04 LTS (focal, ESM) — 1.4.3.6-2ubuntu0.1~esm1; дополнительно cockpit-389-ds, python3-lib389.
  
• Ubuntu 22.04 LTS (jammy) — 2.0.15-1ubuntu2; дополнительно cockpit-389-ds, python3-lib389.
  
• Ubuntu 24.04 LTS (noble) — 2.4.5+dfsg1-1; дополнительно cockpit-389-ds, python3-lib389.
  
• Ubuntu 26.04 LTS (resolute) — 3.1.2+vendor1-2; дополнительно cockpit-389-ds, python3-lib389.
  

Перечисленные версии — это версии, в которых исправление доступно (для ESM-веток — через Ubuntu Pro). Точные границы уязвимых версий внутри веток источники не раскрывают: указано лишь introduced: 0. Оценка severity от Ubuntu — medium.

Причина уязвимости​

Корень проблемы — нарушение границы доверия между открытым и защищённым этапом LDAP-соединения. Протокол StartTLS предполагает, что клиент сначала отправляет запрос перехода на TLS по открытому каналу, а затем обе стороны начинают TLS-рукопожатие, и весь последующий обмен идёт шифрованным.

Ошибка в 389-ds-base в том, что сервер при согласовании StartTLS не отбрасывает открытые байты, уже буферизованные из клиентского соединения до перехода на TLS. Эти байты остаются в очереди чтения и после завершения TLS-апгрейда обрабатываются сервером как легитимный входной поток.

Классификация CWE-923 отражает суть: механизм, который должен ограничивать, какие данные в каком контексте обрабатываются (открытый текст — только до апгрейда), не enforced корректно. Проблему усугубляет сопоставление ответов по messageID: внедрённое сообщение получает тот же идентификатор, что и ожидающая операция клиента, из-за чего ответ на него подменяет ответ на операцию клиента.

Как работает атака​

Путь данных выглядит так. Клиент устанавливает открытое LDAP-соединение с сервером и отправляет данные, которые буферизуются сервером. Затем клиент инициирует StartTLS.

В этот момент атакующий, контролирующий сетевой путь (on-path), внедряет в открытый канал сформированное LDAP-сообщение — оно попадает в тот же буфер, что и легитимные данные клиента.

После завершения TLS-рукопожатия сервер обрабатывает оставшиеся буферизованные байты, включая внедрённое сообщение, как обычный входной поток уже «защищённой» сессии. Проверки целостности TLS на этот поток не распространяются: данные были приняты до апгрейда.

Ключевой эффект возникает на этапе сопоставления ответов. Из-за коллизии messageID ответ сервера на внедрённое сообщение доставляется клиенту как ответ на его собственную ожидающую операцию. Если клиент выполнял bind, он может получить ответ, интерпретируемый как успешная аутентификация, хотя фактически bind завершился неудачей.

Описание механики в источниках ограничивается формулировкой из описания CVE. Детали о том, какие именно типы операций можно внедрять и как формируется коллизия messageID, в доступных материалах не раскрыты.

Условия успешной эксплуатации​

По вектору CVSS и описанию уязвимости для эксплуатации требуются следующие условия:

• Положение на сетевом пути — атакующий должен иметь возможность перехватывать и модифицировать трафик между LDAP-клиентом и сервером (AV:N, on-path-позиция).
  
• Использование StartTLS — соединение должно переходить на TLS именно через StartTLS, а не устанавливаться сразу как LDAPS; при чистом LDAPS открытого этапа, в который можно внедрить данные, нет.
  
• Уязвимая версия 389-ds-base — сервер должен работать на затронутой версии пакета в Ubuntu.
  
• Синхронизация с операцией клиента — внедрённое сообщение должно совпасть по messageID с ожидающей операцией клиента; высокая сложность эксплуатации (AC:H) в векторе CVSS отражает требование точного тайминга.
  

Подтверждённых требований к привилегиям на сервере или к учётным данным нет — по вектору PR:N привилегии не требуются.

Возможный сценарий атаки​

Разумный сценарий (защитный вывод на основе описания CVE, не подтверждённая наблюдаемая атака): атакующий занимает позицию на сетевом пути — например, в скомпрометированном сегменте сети — между LDAP-клиентом, выполняющим аутентификацию через каталог, и сервером 389 Directory Server.

Клиент открывает соединение и запрашивает StartTLS. Пока канал ещё открытый, атакующий внедряет сформированное LDAP-сообщение, совпадающее по messageID с bind-запросом клиента. Соединение переходит на TLS; сервер обрабатывает буферизованные байты, включая внедрённое сообщение.

Ответ на внедрённое сообщение доставляется клиенту как ответ на его bind. Клиентское приложение принимает неудачную аутентификацию за успешную и продолжает работу, полагая, что пользователь аутентифицирован. Практическое следствие — обход аутентификации на стороне клиента в сценариях, где решение о доступе принимается на основании результата bind к каталогу.

Границы сценария: источники не подтверждают использование уязвимости в реальных атаках и не описывают конкретные цели или последствия помимо подмены результата bind.

Есть ли публичный эксплойт​

Доступные источники не содержат сведений о публичном PoC, техническом описании эксплуатации или подтверждённых атаках с использованием CVE-2026-86345. Уязвимость отсутствует в каталоге CISA KEV, а значение EPSS (0,382%, процентиль 29,89%) указывает на низкую прогнозируемую вероятность эксплуатации.

Отсутствие публичного эксплойта не означает, что его не существует: запись CVE имеет статус «Awaiting Analysis» в NVD, и картина может измениться. Техническое описание механики в источнике ограничивается официальным описанием ошибки.

Признаки эксплуатации​

Специфичные индикаторы компрометации (IOC) для этой уязвимости в доступных источниках не опубликованы: нет известных вредоносных хешей, доменов, сигнатур внедрённых сообщений или паттернов журналов, однозначно указывающих на эксплуатацию.

Неспецифичные точки контроля, которые стоит проверять (сами по себе они не подтверждают эксплуатацию):

• журналы доступа 389 Directory Server на предмет аномальных bind-операций и неожиданных последовательностей StartTLS;
  
• сетевые сенсоры на предмет признаков on-path-активности в сегментах с LDAP-трафиком;
  
• корреляция неудачных bind на сервере с «успешными» аутентификациями на стороне клиентских приложений в одно и то же время.
  

Как обнаружить атаку​

Специфичных IOC нет, поэтому обнаружение строится на инвентаризации и общих точках контроля.

Рекомендуемые шаги:

• Инвентаризация — определить, используется ли 389-ds-base в инфраструктуре и на каких версиях; команда dpkg -l | grep 389-ds покажет установленные пакеты.
  
• Проверка конфигурации клиентов — выяснить, какие приложения используют StartTLS (порт 389 с апгрейдом), а не LDAPS (порт 636): именно первые находятся в зоне риска.
  
• Анализ журналов — просмотреть журналы 389 Directory Server на предмет аномалий в bind-операциях и StartTLS-переходах (неспецифичный контроль).
  
• Сетевой мониторинг — отслеживать признаки on-path-активности в сегментах, где ходит LDAP-трафик (неспецифичный контроль).
  

Автоматизированные правила обнаружения, специфичные именно для этой уязвимости, в источниках не описаны.

Как проверить свою версию​

Для проверки версии ОС и состояния пакета используйте следующие команды (замените <имя-пакета> на фактическое имя, например 389-ds-base):

cat /etc/os-release

uname -r

apt-cache policy <имя-пакета>

ubuntu-security-status

Команда apt-cache policy 389-ds-base покажет установленную и доступную версии пакета. ubuntu-security-status отразит, покрыт ли пакет обновлениями безопасности (в том числе через Ubuntu Pro/ESM для старых релизов). Сравните установленную версию с исправленными версиями из раздела «Какие продукты и версии затронуты».

Исправление​

Полное устранение — обновление пакета 389-ds-base до исправленной версии для своего релиза Ubuntu.

Исправленные версии:

• Ubuntu Pro 16.04 LTS — 1.3.4.9-1ubuntu0.1~esm1 (через ESM).
  
• Ubuntu Pro 18.04 LTS — 1.3.7.10-1ubuntu1+esm1 (через ESM).
  
• Ubuntu Pro 20.04 LTS — 1.4.3.6-2ubuntu0.1~esm1 (через ESM).
  
• Ubuntu 22.04 LTS — 2.0.15-1ubuntu2.
  
• Ubuntu 24.04 LTS — 2.4.5+dfsg1-1.
  
• Ubuntu 26.04 LTS — 3.1.2+vendor1-2.
  

Обновление выполняется стандартным способом:

sudo apt update && sudo apt upgrade 389-ds-base

Для релизов 16.04–20.04 требуется активная подписка Ubuntu Pro (ESM), поскольку исправления выпущены в репозиториях esm-apps. После обновления перезапустите службу каталогов, чтобы новый код вступил в силу. Точное имя службы в источниках не указано; проверьте его командой systemctl list-units | grep -i dirsrv или аналогичной.

Временные меры защиты​

Источники не описывают официальных временных мер (mitigations) от вендора. Исходя из механики уязвимости, разумные защитные выводы:

• Перевести клиентов на LDAPS (порт 636) — при соединении сразу по TLS открытого этапа, в который можно внедрить данные, не возникает; это устраняет необходимое условие атаки.
  
• Отключить StartTLS на сервере, если все клиенты поддерживают LDAPS, — тем же механизмом.
  
• Сегментация сети — изолировать LDAP-трафик в выделенном сегменте, затруднив атакующему занятие on-path-позиции.
  
• Контроль канального уровня — механизмы защиты от ARP-спуфинга (dynamic ARP inspection, статические ARP-записи) снижают возможность перехвата в локальном сегменте.
  

Это компенсирующие меры, а не исправление: обновление остаётся обязательным.

Как проверить устранение уязвимости​

После обновления проверьте, что установлена исправленная версия и служба работает с новым кодом.

Проверка версии пакета:

apt-cache policy 389-ds-base

Установленная версия должна соответствовать исправленной для вашего релиза (см. раздел «Исправление»). Дополнительно:

• dpkg -l 389-ds-base — подтвердит установленную версию пакета.
  
• ubuntu-security-status — покажет, что пакет больше не числится с незакрытыми уязвимостями.
  
• Проверьте статус службы каталогов после перезапуска и выполните контрольный bind-запрос от клиентского приложения, чтобы убедиться в корректной работе аутентификации.
  

Автоматизированный тест на отсутствие уязвимого поведения в источниках не описан.

Вывод​

CVE-2026-86345 — ошибка в 389-ds-base в Ubuntu, при которой сервер не отбрасывает буферизованные открытые байты при согласовании StartTLS. Атакующий на сетевом пути может внедрить LDAP-сообщение, ответ на которое из-за коллизии messageID клиент принимает за ответ на свою операцию — вплоть до трактовки неудачного bind как успешной аутентификации.

Оценки критичности расходятся: Red Hat даёт CVSS 9.0 (CRITICAL), Ubuntu — medium. EPSS низкий (0,382%), в CISA KEV уязвимость отсутствует, публичных эксплойтов и подтверждённых атак в источниках не зафиксировано. Тем не менее условие эксплуатации — положение на сетевом пути — реалистично для скомпрометированных сегментов, а следствие (обход аутентификации на стороне клиента) существенно.

Приоритетные действия: обновить 389-ds-base до исправленной версии для своего релиза (для 16.04–20.04 — через Ubuntu Pro/ESM), а до обновления — перевести клиентов с StartTLS на LDAPS и усилить сегментацию сети вокруг LDAP-трафика.

Официальные источники​

1. NVD — CVE-2026-86345
   
2. Ubuntu OSV — CVE-2026-86345
   
3. FIRST EPSS — CVE-2026-86345
   

История обновлений статьи​

• 06.10.2026 — Опубликована первая версия материала.