Apache Tomcat 11.0.25 получил релизный тег 12 августа 2026 года и меняет настройку, которая могла годами оставаться незаметной в конфигурации кластера: EncryptInterceptor теперь использует AES/GCM/NoPadding по умолчанию, причём разработчики прямо пометили переход как breaking change. В той же версии усилены проверки HTTP/2 и WebSocket, появился лимит заголовков при WebSocket Upgrade и закрыта CVE-2026-66299, способная довести процесс Tomcat до исчерпания памяти через демонстрационный чат.
EncryptInterceptor переходит с CBC на AES-GCM
До версии 11.0.25 EncryptInterceptor, который шифрует сообщения между узлами кластера Tomcat, по умолчанию использовал AES/CBC/PKCS5Padding. Этот режим сохранялся ради обратной совместимости. В официальном changelog Apache Tomcat 11.0.25 значение по умолчанию заменено на AES/GCM/NoPadding, а само изменение помечено как breaking change.
GCM относится к режимам аутентифицированного шифрования: вместе с конфиденциальностью он позволяет проверять целостность сообщения. В документации к EncryptInterceptor разработчики одновременно расширили пояснения о слабых сторонах поддерживаемых алгоритмов и уточнили, что защита от повторной передачи сообщений работает полноценно только с немодифицируемыми криптографическими схемами.
Если несколько узлов обмениваются данными сессий через EncryptInterceptor и полагаются на значение encryptionAlgorithm по умолчанию, Tomcat 11.0.24 выбирает CBC, а Tomcat 11.0.25 — GCM. Узлы с разными алгоритмами не смогут расшифровать сообщения друг друга. Именно поэтому переход вынесен в changelog как изменение совместимости, хотя номер версии выглядит как обычное точечное обновление.
В Tomcat 11.0.24 разработчики в основном исправляли отдельные ошибки в DIGEST-аутентификации, RewriteValve, JSP и WebSocket. Версия 11.0.25 затрагивает уже значения по умолчанию в кластерной подсистеме и тем самым меняет поведение конфигураций, где этот параметр явно не задавался.
HTTP/2 теперь строже проверяет authority и идентификаторы потоков
В Coyote, сетевом слое Tomcat, сразу несколько исправлений относятся к HTTP/2. При переходе с HTTP/1.1 на HTTP/2 сервер теперь завершает обработку всех данных исходного HTTP/1.1-запроса до переключения протокола. Такой порядок убирает пограничную ситуацию, в которой смена протокола могла начаться раньше завершения обработки входного потока.
Каждый HTTP/2-запрос теперь обязан содержать информацию об узле назначения через псевдозаголовок :authority либо обычный заголовок Host. Одновременно Tomcat раньше регистрирует идентификатор HTTP/2-потока, поэтому повторно использованный stream ID не принимается даже тогда, когда ошибка обнаружена на ранней стадии разбора HEADERS frame.
Ещё одно изменение связано с распределением памяти. В системе отслеживания backlog для протокола HTTP/2 наблюдалась утечка памяти при завершении потока. В версии 11.0.25 этот дефект был устранён. Для серверов с большим числом быстро завершающих работу HTTP/2-соединений проблема заключалась именно в накоплении внутренних ресурсов при RST_STREAM, а не в объёме передаваемых данных.
NIO получил дополнительные проверки Unix Domain Sockets
NIO-коннектор пополнился параметрами unixDomainSocketParentPermissions и unixDomainSocketParentOwner. Они управляют правами и владельцем родительского каталога, в котором создаётся Unix Domain Socket. Проверки самого каталога включены по умолчанию.
Такой сокет часто используется как локальный канал между процессами на одном сервере. В схеме с reverse proxy и Tomcat безопасность зависит в том числе от того, кто способен создавать или подменять объект сокета в файловой системе. Новые параметры переносят эту часть контроля непосредственно в конфигурацию коннектора и делают проверку каталога частью штатного запуска.
WebSocket получил лимит 8 КБ и исправление CVE-2026-66299
Самое наглядное исправление безопасности связано с приложением-примером, которое поставляется вместе с Tomcat. В WebSocket-чате очередь недоставленных сообщений могла расти без ограничения. Злоумышленнику было достаточно поддерживать очень медленное соединение, чтобы сообщения накапливались в памяти и со временем привели к её исчерпанию и остановке процесса Tomcat.
Apache присвоил проблеме идентификатор CVE-2026-66299 и оценил её уровень как Low. Уязвимость затрагивает Tomcat от 11.0.0-M20 до 11.0.24. Инсталляции, из которых приложение examples было удалено согласно рекомендациям проекта по безопасности, под действие этой CVE не попадают. В 11.0.25 буферизация сообщений демонстрационного чата ограничена.
Одновременно WebSocket-клиент Tomcat получил отдельный предел для HTTP-заголовков ответа во время процедуры Upgrade. Значение по умолчанию составляет 8 КБ и задаётся через пользовательское свойство org.apache.tomcat.websocket.MAX_HTTP_RESPONSE_HEADER_BYTES. Так у стадии установления WebSocket-соединения появился собственный явный предел на объём принимаемых заголовков.
Изменилось и сопоставление URI-шаблонов WebSocket endpoint. Завершающий / теперь имеет значение и в определении шаблона, и в URI, который сравнивается с ним. Приложения, где маршруты фактически полагались на одинаковую трактовку адресов с завершающим слешем и без него, могут увидеть другое сопоставление endpoint.
Tomcat 11.0.25 учитывает и смену идентификатора HTTP-сессии при отслеживании WebSocket-соединений, созданных после аутентификации. Когда такая HTTP-сессия завершается, сервер получает более точную связь между ней и открытыми WebSocket-соединениями даже после изменения session ID.
URL-паттерны получили переходный режим перед Tomcat 12
Одна из самых интересных доработок Catalina связана с тем, как Tomcat понимает URL-паттерны из web.xml, аннотаций и программной конфигурации. Спецификация Servlet требует передавать такие значения в декодированном виде. Исторически Tomcat трактовал их как закодированные URL, включая последовательности вида %nn.
В 11.0.25 у Context появился параметр urlPatternsProvidedInDecodedForm. Он позволяет выбирать трактовку URL-паттернов для каждого приложения отдельно. Разработчики прямо связывают этот параметр с переходом на Tomcat 12: в следующей основной ветке паттерны будут всегда считаться декодированными, а временная настройка исчезнет.
Получается своеобразный мост между историческим поведением Tomcat и требованиями Servlet. Приложение может работать на Tomcat 11 с прежней семантикой либо включить будущий вариант обработки ещё в текущей ветке. Для проектов со сложными security constraints, фильтрами и servlet mappings различие проявляется в том, какой именно путь сервер сравнивает с правилами из конфигурации.
Связанное изменение касается выбора ограничений безопасности. Если запрос подходит сразу под несколько security-constraint, Tomcat 11.0.25 выбирает правило с самым длинным совпавшим путём. Для FORM-аутентификации сервер повторно оценивает ограничения после восстановления сохранённого запроса, если исходный HTTP-метод отличался от GET. В changelog отдельно указано, что кастомные Authenticator, наследующие FormAuthenticator и переопределяющие doAuthenticate() или restoreRequest(), затрагиваются этим изменением поведения.
DataSourceRealm и конфигурация web.xml стали строже при ошибках
DataSourceRealm теперь завершает аутентификацию неуспехом, если соединение с базой данных недоступно либо при поиске пользователя или ролей возникает исключение. Раньше в некоторых таких сценариях мог формироваться частично заполненный Principal. Для CLIENT-CERT и SPNEGO добавлено ещё одно условие: пользователь должен присутствовать в базе данных, связанной с Realm.
В обработке deployment descriptor появился другой жёсткий сценарий. Конфликт login-config при объединении фрагментов web.xml теперь приводит к ошибке развёртывания приложения. Сервер тем самым прекращает запуск конфигурации, где разные части descriptor задают несовместимые параметры аутентификации.
Исправлена и гонка между добавлением атрибута в HTTP-сессию и её истечением. После 11.0.25 приложение получает одно из двух последовательных состояний: атрибут успешно добавлен до завершения сессии либо операция добавления не проходит. Сценарий, при котором сессия уже истекла, а добавление атрибута всё же считается успешным, исключён. Это особенно заметно для объектов, реализующих HttpSessionBindingListener, поскольку они получают события привязки к сессии.
RewriteValve, каталог файлов и зависимости получили точечные правки
В RewriteValve исправлена оценка флагов N и C, а флаг qsd теперь всегда отбрасывает исходную query string при переписывании URL. Для subject name и issuer name сертификатов в rewrite-правилах применяется формат RFC 2253. Ещё одна правка устраняет ошибочный отказ DIGEST-аутентификации, когда nonce count клиента находился ровно на верхней границе разрешённого окна.
Default Servlet корректнее экранирует context path, имя текущего каталога и имя родительского каталога в генерируемых списках файлов. Для XML-вывода используется XML-экранирование. Эти изменения закрывают класс проблем, где служебное имя из файловой структуры могло попасть в сформированный ответ без подходящего экранирования.
В Jasper сбрасывается внутреннее состояние ELParser перед повторным использованием. В документации исправлены ссылки на Servlet 6.1, а Manager загружает классы кластеризации через reflection на странице списка сессий, благодаря чему она корректно формируется и без clustering JAR.
Набор встроенных зависимостей тоже обновился: Maven Resolver Ant Tasks до 1.6.1, Objenesis до 3.6, JSign до 7.5 и Bouncy Castle до 1.85. Эти изменения сопровождают основной набор исправлений и входят в тот же релизный тег 11.0.25.
Tomcat 11.0.25 связывает текущую ветку с будущим Tomcat 12
По сравнению с 11.0.24 новая версия заметнее вмешивается в поведение протоколов и механизмов безопасности. Три изменения могут проявиться без правок прикладного кода: новый алгоритм EncryptInterceptor по умолчанию, более строгая семантика завершающего / в WebSocket URI и переходный режим декодированных URL-паттернов.
При этом CVE-2026-66299 имеет узкую область воздействия: проблема находится в демонстрационном WebSocket-чате, Apache оценивает её как Low, а установки без приложения examples ей не подвержены. Рядом с этим исправлением релиз меняет куда более фундаментальные детали — шифрование кластера, обработку HTTP/2, Realm-аутентификацию и выбор security constraints.
Параметр urlPatternsProvidedInDecodedForm уже описан как временный механизм: Tomcat 12 будет всегда работать с декодированными URL-паттернами. Поэтому 11.0.25 одновременно фиксирует текущую ветку и обозначает конкретную границу совместимости с будущей основной версией. Масштаб реального влияния зависит от того, сколько действующих кластеров полагаются на прежний CBC по умолчанию и сколько WebSocket-приложений зависят от старой трактовки завершающего слеша — такой статистики проект не публикует.
