Apache Tomcat получил исправления для тринадцати уязвимостей сразу в трёх поддерживаемых ветках. Закрывающие правки вошли в выпуски 10.1.60, 11.0.26 и 9.0.122, опубликованные 23 сентября. Уязвимы сборки 10.1.x младше 10.1.60, 11.0.x младше 11.0.26 и 9.0.x младше 9.0.122. Последствия разнятся: от удалённого отказа в обслуживании до подмены заголовков запросов и обхода ограничений доступа к WebSocket-узлам. Tomcat используют во множестве корпоративных и государственных сервисов, поэтому обновление касается не только разработчиков, но и администраторов, которые отвечают за доступность приложений и за сохранность данных в них.
Детали уязвимостей
О найденных проблемах сообщали в течение месяца, с 11 августа по 7 сентября. Публичными они стали одновременно с выпуском правок. Разработчики делят их на три ступени: важные, умеренные и незначительные. Такая шкала не заменяет числовой оценки, но показывает, каким местам команда уделила больше внимания. Важных пунктов в списке четыре, умеренных три, остальные помечены как незначительные.
Уязвимость CVE-2026-86350 затрагивает HTTP/2 и появилась из-за предыдущего исправления CVE-2026-41293. Разное толкование запросов в одном соединении приводит к тому, что заголовки одного пользователя попадают в запрос другого. Проблема касается узкого диапазона сборок: 10.1.55-10.1.59, 11.0.22-11.0.25 и 9.0.118-9.0.121. Проще говоря, рискуют те, кто обновился в последние месяцы. Дальнейшее зависит от приложения. Если оно доверяет данным из заголовков, подмена открывает путь к чужой сессии или к операции, выполненной от чужого имени. Регрессия появилась в правке, которая сама закрывала похожую проблему, и это отдельный повод проверить журналы на предмет необычных запросов по HTTP/2.
Вторая важная уязвимость CVE-2026-76183 позволяет обойти ограничения безопасности для WebSocket-узлов. Пути запросов разбираются как шаблоны конечных точек, и при определённом написании адреса проверка доступа не срабатывает. Злоумышленник получает доступ к обработчикам, которые приложение должно было закрыть от посторонних. Проблема есть во всех сборках трёх веток, включая последние, поэтому ей подвержены и те, кто ставит обновления без задержек.
Отказ в обслуживании упоминается четыре раза. Уязвимость CVE-2026-78383 связана с протоколом AJP, который соединяет Tomcat с внешним веб-сервером. Если пользователь не передал тело запроса, поток обработки остаётся занятым и перестаёт обслуживать остальных. Ещё одна уязвимость срабатывает при закрытии соединения WebSocket: обработчик уходит в активное ожидание, то есть в цикл, который загружает процессор вхолостую. Третья вызвана потерей тайм-аутов асинхронной записи из-за состояния гонки. Четвёртая связана с некорректным запросом по HTTP/2, который при совпадении по времени приводит к сбою чужого запроса. Для части таких сценариев права в приложении не нужны, достаточно отправить поток запросов.
Ещё часть уязвимостей угрожает целостности данных и аутентификации. При сжатии сообщений в WebSocket неверная обработка длины позволяет встраивать посторонние данные в поток и смешивать границы сообщений. Гонка в механизме сжатия заголовков HTTP/2 приводит к тому, что служебные поля одного запроса попадают в другой, взятый из пула. Обработка заголовка, описывающего передачу данных блоками (фрагментированная передача), для устаревшего HTTP/1.0 даёт возможность сорвать чужой запрос, когда перед Tomcat стоит обратный прокси.
Отдельная группа касается TLS-соединений и проверки клиентов. Реализации TLS на основе OpenSSL и FFM игнорируют списки отозванных сертификатов, если сертификат взят из хранилища ключей. Отозванный сертификат продолжает приниматься, и работа с отзывом теряет смысл. Хранилище ключей применяют во многих промышленных конфигурациях, поэтому проблема затрагивает не единичные установки. Проверка статуса сертификата по протоколу OCSP в ряде сценариев не приводит к отказу в аутентификации клиента, хотя должна. Ещё одна уязвимость проявляется при настройке Jakarta Authentication: если несколько веб-приложений пользуются общим провайдером, берётся область того приложения, которое первым обработало запрос. Пользователь одного сервиса может получить права другого.
Исправления доступны в выпусках 10.1.60, 11.0.26 и 9.0.122. Администраторам нужно обновить Tomcat до этих версий или более новых. Ветка 9.0 продолжает получать правки, потому что её используют в унаследованных системах. Обратный прокси и балансировщик перед Tomcat тоже требуют внимания: часть уязвимостей проявляется только в такой схеме. Сведений об эксплуатации перечисленных проблем в реальных атаках разработчики не приводят.
Оценка риска зависит от того, какие возможности приложения открыты наружу. Сервис, который держит длительные соединения и сжатие сообщений, получает больше поводов обновиться. Публичный портал с аутентификацией клиентов по сертификатам тоже в группе риска. Внутренняя установка для сборки и тестов переживёт задержку, но и её не стоит оставлять без правок. Обновление стоит установить и потому, что Tomcat часто работает не сам по себе, а в связке с внешним веб-сервером и балансировщиком нагрузки.
Тринадцать уязвимостей в одном выпуске - обычная картина для проекта, который держит несколько веток и переписывает реализацию HTTP/2 и WebSocket. Примечательно другое: одна из проблем появилась из-за предыдущего исправления. Регрессии в правках безопасности встречаются всё чаще, и это довод в пользу того, чтобы проверять приложения после каждого обновления, а не ограничиваться установкой. Особенно там, где Tomcat стоит за прокси и обслуживает несколько приложений с общей аутентификацией.
Ссылки
- https://tomcat.apache.org/security-10.html#Fixed_in_Apache_Tomcat_10.1.60
- https://tomcat.apache.org/security-11.html#Fixed_in_Apache_Tomcat_11.0.26
- https://tomcat.apache.org/security-9.html#Fixed_in_Apache_Tomcat_9.0.122
