CVE-2026-65905 в Debian: обход DIGEST-аутентификации в Apache Tomcat

CVE: CVE-2026-65905
Продукт: Debian
Дата публикации: 26.08.2026
Критичность: CRITICAL
CVSS: 9.8 (3.1)
EPSS: 0,68%; процентиль 49,65%
CISA KEV: нет подтверждения в каталоге CISA KEV

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

В Apache Tomcat обнаружен дефект в DIGEST-аутентификаторе, позволяющий обходить проверку подлинности через повторное использование перехваченного запроса. Ошибка затрагивает широкий диапазон версий, включая пакеты tomcat10 и tomcat11 в Debian, для которых на момент публикации исправления в репозиториях отсутствуют. Материал описывает механику атаки, статус обновлений и временные меры защиты.

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

Дефект нарушает логику защиты от replay-атак, допуская повторное использование запроса с определённым значением счётчика nonceCount. Атакующий, перехвативший валидный DIGEST-запрос, может повторить его и получить доступ к ресурсам без знания пароля.

• Классификация: CWE-294 (Authentication Bypass by Capture-replay). Ошибка в проверке границ replay-окна.
  
• CVSS 3.1: 9.8 (CRITICAL). Вектор: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Оценка отражает сетевой вектор, отсутствие требований к привилегиям и полный компромисс конфиденциальности, целостности и доступности.
  
• Эксплуатация: В каталоге CISA KEV CVE-2026-65905 не числится. Публичные PoC или подтверждённые атаки в предоставленных источниках не зафиксированы.
  
• EPSS: 0,68% (процентиль 49,65%). Вероятность эксплуатации в ближайшие 30 дней оценивается как низкая, но близкая к медиане по всем CVE.
  

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

Уязвимость затрагивает Apache Tomcat в версиях от 7.0.30 до 11.0.24 (исключая исправленные релизы). В контексте Debian это касается пакетов tomcat9, tomcat10 и tomcat11.

Согласно данным Debian Security Tracker, статус исправлений на момент публикации статьи выглядит следующим образом:

• tomcat9: Статус resolved для всех поддерживаемых и EOL-релизов (bullseye, bookworm, trixie, forky, sid). Исправленная версия пакета: 9.0.70-2 (для bookworm) и соответствующие security-обновления для других релизов.
  
• tomcat10: Статус open для bookworm, trixie, forky и sid. В репозиториях Debian (включая security) установлена версия 10.1.55-1~deb12u1 (bookworm) или 10.1.55-1 (forky/sid), которая не содержит исправления. Официальный фикс ожидается в версии 10.1.58.
  
• tomcat11: Статус open для trixie, forky и sid. В репозиториях установлена версия 11.0.22-1~deb13u1 (trixie) или 11.0.24-1 (forky/sid), которая не содержит исправления. Официальный фикс ожидается в версии 11.0.25.
  

Пакеты tomcat8 и tomcat7 в актуальных репозиториях Debian отсутствуют, так как эти ветки Tomcat давно выведены из поддержки.

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

Причина дефекта кроется в логике валидации параметра nonceCount в DIGEST-аутентификаторе Apache Tomcat. Механизм DIGEST использует nonce (одноразовый токен) и счётчик запросов (nonceCount) для предотвращения повторного использования перехваченных данных.

В уязвимых версиях существует ошибка в проверке границ replay-окна. Если клиент отправляет запрос с nonceCount, равным верхней границе допустимого окна (windowSize), до того как будет сделано windowSize запросов, сервер ошибочно считает этот запрос валидным.

Это позволяет атакующему, перехватившему такой запрос, повторить его (replay) один раз, пока соответствующий nonceCount остаётся в пределах окна. Ошибка нарушает предположение о том, что каждый nonceCount может быть использован только один раз в рамках сессии.

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

Атака строится на перехвате сетевого трафика, содержащего DIGEST-аутентификацию. Атакующий не знает пароль пользователя, но перехватывает HTTP-запрос, прошедший аутентификацию.

Ключевым условием является значение nonceCount в перехваченном запросе. Если это значение находится на верхней границе replay-окна (но не превышает его), и при этом общее количество запросов в сессии ещё не исчерпало лимит windowSize, сервер примет повторный запрос как валидный.

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

Атака не требует взлома хеша пароля или подбора ключей. Она эксплуатирует временное окно, в котором сервер ещё не «забыл» о сессии, но логически ошибается в проверке повторного использования конкретного счётчика.

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

Для успешной эксплуатации атакующему необходимо выполнить следующие условия:

• Перехват трафика: Атакующий должен находиться в сети между клиентом и сервером (man-in-the-middle) или иметь доступ к сетевому трафику, чтобы перехватить валидный DIGEST-запрос.
  
• Использование DIGEST-аутентификации: Целевая система должна использовать механизм DIGEST для аутентификации. Если используется Basic, Form или другие механизмы, дефект неприменим.
  
• Точное значение nonceCount: Перехваченный запрос должен содержать nonceCount, равный верхней границе replay-окна. Если значение ниже границы, повторный запрос будет отклонён как replay-атака.
  
• Временное окно: Повторный запрос должен быть отправлен до истечения replay-окна (пока сервер ещё хранит состояние сессии и считает nonceCount валидным).
  
• Отсутствие дополнительных защит: Если на уровне сети или приложения используются дополнительные механизмы защиты от replay-атак (например, строгие проверки на уровне WAF или TLS-шифрование с взаимной аутентификацией), атака может быть затруднена.
  

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

Сценарий начинается с перехвата трафика. Атакующий, находясь в сети, перехватывает HTTP-запрос, отправленный легитимным пользователем с DIGEST-аутентификацией. В заголовке Authorization содержится nonce, nc (nonceCount) и response.

Атакующий анализирует перехваченный запрос. Если значение nc соответствует верхней границе replay-окна (например, nc=00000005 при windowSize=5), и при этом сессия ещё активна, атакующий готовит повторный запрос. Он копирует все заголовки перехваченного запроса, включая Authorization.

Атакующий отправляет этот запрос на сервер. Сервер проверяет nonce и nc. Из-за дефекта в логике проверки границ, сервер не распознаёт, что этот nc уже был использован в пределах окна, и принимает запрос как валидный.

Сервер обрабатывает запрос, предоставляя атакующему доступ к защищённым ресурсам под учётными данными жертвы. Атакующий может выполнить действия, которые были разрешены жертве, включая чтение данных, изменение состояния или выполнение команд, если приложение позволяет.

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

На момент публикации статьи в предоставленных источниках (NVD, Debian Security Tracker, Apache Mailing List) отсутствуют сведения о публичных PoC, готовых эксплоитах или подтверждённых атаках в дикой природе.

• PoC: Не обнаружено публичных proof-of-concept скриптов в репозиториях GitHub или на форумах, ссылающихся на CVE-2026-65905.
  
• Техническое описание: Официальное уведомление Apache содержит техническое описание механизма дефекта, но не предоставляет готового кода для эксплуатации.
  
• Подтверждённая эксплуатация: В каталоге CISA KEV CVE-2026-65905 не числится. Нет сообщений о массовых атаках или компрометациях, связанных с этим дефектом.
  

Отсутствие публичного эксплойта не означает, что атака невозможна. Механика описана достаточно подробно, чтобы квалифицированный атакующий мог разработать собственный эксплойт на основе перехвата трафика.

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

Специфичные IOC (индикаторы компрометации) для CVE-2026-65905 в предоставленных источниках не описаны. Однако можно выделить общие признаки, которые могут указывать на попытку эксплуатации:

• Аномальные повторные запросы: В логах Tomcat могут наблюдаться повторные HTTP-запросы с одинаковым nonce и nc в коротком временном интервале. Нормальный клиент не повторяет запрос с тем же nc в пределах replay-окна.
  
• Запросы с граничными значениями nonceCount: Запросы, где nc равно верхней границе окна (например, 00000005 при windowSize=5), особенно если они приходят от IP-адресов, не связанных с легитимными пользователями.
  
• Успешная аутентификация без ввода пароля: Если система ведёт логи аутентификации, можно заметить успешные входы, для которых не было предшествующих запросов на получение nonce или которые приходят от подозрительных IP.
  

Эти признаки неспецифичны и могут быть вызваны другими причинами (например, сбоями клиента или повторными запросами из-за сетевых проблем). Их наличие требует дополнительной проверки.

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

Для обнаружения атаки на CVE-2026-65905 рекомендуется настроить мониторинг логов Apache Tomcat и сетевых потоков.

• Мониторинг логов Tomcat: Включите логирование заголовков Authorization (с маскированием чувствительных данных) или используйте WAF для записи DIGEST-запросов. Ищите паттерны повторных запросов с одинаковым nonce и nc.
  
• Анализ сетевых потоков: Если доступен, анализируйте HTTP-трафик на предмет повторных запросов с одинаковыми параметрами DIGEST-аутентификации. Инструменты вроде Zeek или Suricata могут помочь в выявлении аномалий.
  
• Корреляция с журналом аутентификации: Сопоставляйте успешные входы с временными метками запросов. Если вход происходит сразу после перехваченного запроса с граничным nc, это может быть признаком атаки.
  

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

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

Для проверки, установлена ли уязвимая версия Tomcat в системе Debian, выполните следующие команды. Замените <имя-пакета> на фактическое имя пакета (tomcat9, tomcat10 или tomcat11).

# Проверка версии Debian
cat /etc/debian_version
cat /etc/os-release

# Проверка версии установленного пакета Tomcat
apt-cache policy <имя-пакета>
dpkg-query -W -f='${Package} ${Version}\n' <имя-пакета>

Сравните полученную версию с данными из Debian Security Tracker:

• Для tomcat9: если версия 9.0.70-2 или выше, система защищена.
  
• Для tomcat10: если версия 10.1.55-1~deb12u1 или ниже, система уязвима. Ожидается обновление до 10.1.58.
  
• Для tomcat11: если версия 11.0.24-1 или ниже, система уязвима. Ожидается обновление до 11.0.25.
  

Если пакет не установлен, дефект не актуален для данной системы.

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

Единственным надёжным способом устранения дефекта является обновление Apache Tomcat до исправленных версий.

• Для tomcat9: Убедитесь, что установлен пакет версии 9.0.70-2 или выше. В Debian это уже выполнено для всех релизов. Проверьте с помощью dpkg-query.
  
• Для tomcat10 и tomcat11: На момент публикации статьи исправления ещё не выпущены в репозиториях Debian. Ожидается обновление до версий 10.1.58 и 11.0.25 соответственно. Подпишитесь на рассылку Debian Security и следите за анонсами.
  

Пока исправление не выпущено, рассмотрите временные меры защиты (см. раздел «Временные меры защиты»). После выпуска обновлений выполните:

apt update
apt upgrade <имя-пакета>

Перезапустите Tomcat после обновления:

systemctl restart tomcat10
# или
systemctl restart tomcat11

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

Пока исправление для tomcat10 и tomcat11 не выпущено в Debian, можно применить следующие временные меры:

• Отключение DIGEST-аутентификации: Если возможно, переключите приложение на другой механизм аутентификации (например, Form, Basic с TLS или JWT). Это полностью устранит вектор атаки.
  
• Ограничение доступа по IP: Если DIGEST-аутентификация используется только для внутренних сервисов, ограничьте доступ к ним по IP-адресам через firewall (iptables/nftables). Это снизит вероятность перехвата трафика.
  
• Усиление TLS: Убедитесь, что все соединения с Tomcat защищены TLS 1.2 или выше. Это затруднит перехват трафика, но не исключит его полностью, если атакующий имеет доступ к сети.
  
• Мониторинг: Усиленный мониторинг логов Tomcat на предмет аномальных повторных запросов (см. раздел «Обнаружение»).
  

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

После обновления пакета Tomcat до исправленной версии выполните следующие шаги для проверки:

1. Проверка версии:
   
   

   dpkg-query -W -f='${Package} ${Version}\n' <имя-пакета>

   
   Убедитесь, что версия соответствует исправленной (например, 10.1.58 для tomcat10 или 11.0.25 для tomcat11).
   
2. Перезапуск сервиса:
   
   

   systemctl restart tomcat10
   systemctl status tomcat10

   
   Убедитесь, что сервис работает без ошибок.
   
3. Функциональное тестирование:
   Проверьте, что DIGEST-аутентификация работает корректно. Отправьте тестовый запрос с валидными учётными данными и убедитесь, что он проходит аутентификацию.
   
4. Проверка на уязвимость:
   Если возможно, проведите тестирование на повторный запрос (replay) с граничным nonceCount. Убедитесь, что сервер отклоняет повторный запрос как невалидный.
   

Вывод​

CVE-2026-65905 представляет собой критический дефект в механизме DIGEST-аутентификации Apache Tomcat, позволяющий обходить аутентификацию через replay-атаку. В Debian пакеты tomcat9 уже обновлены, но tomcat10 и tomcat11 на текущих релизах остаются уязвимыми до выпуска официальных обновлений.

Администраторам Debian рекомендуется:

1. Проверить установленные версии Tomcat с помощью команд из раздела «Проверка версии».
   
2. Если используется tomcat10 или tomcat11, применить временные меры защиты (отключение DIGEST, ограничение IP, усиление TLS).
   
3. Подписаться на рассылку Debian Security и установить обновления сразу после их выпуска.
   
4. Усилить мониторинг логов Tomcat на предмет аномальных повторных запросов.
   

Дефект не требует публичного эксплойта для эксплуатации, поэтому не следует полагаться на отсутствие атак в дикой природе. Активная защита и своевременное обновление являются ключевыми мерами.

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

1. NVD — CVE-2026-65905
   
2. Debian Security Tracker — CVE-2026-65905
   
3. FIRST EPSS — CVE-2026-65905
   

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

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