12 октября 2026 года проект Apache Tomcat объявил о выпуске версий 11.0.27, 10.1.61 и 9.0.123. Все три обновления устраняют ошибку обработки буфера, из-за которой содержимое загружаемых файлов могло повреждаться при сочетании HTTP/2 и асинхронного ввода-вывода. В числе затронутых сценариев автор исправления назвал передачу больших файлов из Safari через защищённое соединение.
Ошибка в SocketBufferHandler могла незаметно изменить содержимое загружаемого файла
Проблема обнаружилась в методе SocketBufferHandler.unReadReadBuffer(), который работает с уже прочитанными из сетевого соединения байтами. Когда серверу требовалось сдвинуть данные внутри буфера и вернуть часть байтов на повторное чтение, прежний алгоритм копировал их от начала к концу. При перекрытии исходного и целевого участков такая операция могла перезаписать байты до того, как программа успевала их прочитать.
Представим буфер с последовательностью A B C D E F. Если перед существующими данными нужно освободить место для двух новых байтов, прямое копирование с перекрытием способно размножить начальные символы и потерять часть исходной последовательности. Для загрузки файла это означает риск получить изменённое содержимое, хотя клиент отправил другие данные.
Разработчик Тим Бёрк описал такой сценарий 25 сентября в pull request №1073. Он указал на загрузки через HTTP/2, асинхронный I/O и TLS, отдельно упомянув большие файлы из браузера Safari. В исправленном алгоритме байты перемещаются в обратном направлении, а регрессионные тесты проверяют случай с перекрывающимися участками памяти.
Условия ошибки достаточно специфичны: из описания нельзя сделать вывод, что она затрагивала каждую загрузку по HTTP/2. Но для сервисов, которые принимают пользовательские документы, фотографии или другие файлы, сам механизм порчи данных важнее внешнего симптома — проблема возникает на уровне сетевого буфера до обычной обработки файла приложением.
Tomcat уточнил обработку HTTP/2 и исправил ещё один сценарий повреждения данных
В тех же версиях исправили учёт окна управления потоком HTTP/2. Когда часть тела запроса поступала на сервер, но приложение её не считывало, возникала утечка доступного размера окна соединения. Это окно определяет, какой объём данных можно передать без дополнительного разрешения от получателя. Ошибка в его учёте могла мешать дальнейшей передаче данных в соответствующих условиях.
Разработчики устранили узкую гонку при обработке HTTP/2-заголовков и усилили поведение сервера при асинхронных ошибках, которые приложение обрабатывает некорректно. Отдельное исправление касается HTTP/1.1: после неудачной записи одного фрагмента ответа последующее тело с передачей chunked могло оказаться повреждённым. Здесь речь идёт уже об ответе сервера клиенту, тогда как ошибка unReadReadBuffer() затрагивала входящую загрузку.
Есть изменения и для AJP — протокола обмена между Tomcat и внешним веб-сервером. Исправлены ситуации, при которых крупная неблокирующая запись могла остановиться или завершиться до опустошения буфера. Такие случаи относятся к конфигурациям, где Tomcat обслуживает Java-приложение за прокси-сервером с AJP-соединением.
Исправления TLS и кластерных сессий затрагивают другие конфигурации Tomcat
В релизах также исправлена ошибка TLS-рукопожатия при использовании реализаций SSLEngine на базе OpenSSL. Она проявлялась, когда первый набор сообщений, отправляемых сервером, не помещался во внутренний буфер. В объявлении отдельно упомянуты большие подписи ML-DSA — алгоритма цифровой подписи, связанного с постквантовой криптографией. Ранее такое соединение могло остановиться на этапе согласования TLS.
Для кластерных установок разработчики исправили несколько возможных взаимных блокировок в DeltaSession. Они связаны с изменением атрибутов, завершением сессий и обменом их изменениями между узлами. В прежней реализации разные операции могли ожидать освобождения блокировок друг друга. Исправления меняют порядок получения блокировок и обработки данных сессий.
Ещё одна доработка касается StoreConfig: при повторном сохранении существующих server.xml и файлов контекстов Tomcat теперь по возможности сохраняет комментарии, пустые строки и порядок атрибутов. Для администраторов это сокращает число посторонних различий между конфигурационными файлами до и после сохранения.
Tomcat 9, 10 и 11 получили общее исправление при разных требованиях к Java
Обновления вышли одновременно для трёх поддерживаемых веток, которые рассчитаны на разные версии Java и серверных спецификаций.
| Релиз | Платформа приложений | Минимальная версия Java |
| Tomcat 11.0.27 | Jakarta EE 11, Servlet 6.1 | Java 17 |
| Tomcat 10.1.61 | Jakarta EE 10, Servlet 6.0 | Java 11 |
| Tomcat 9.0.123 | Java EE 8, Servlet 4.0 | Java 8 |
Такое разделение существенно для приложений со старым пространством имён javax.. Начиная с Tomcat 10 серверные API используют jakarta., и переход с Tomcat 9 на старшие ветки может потребовать изменения приложения. Выпуск исправления в Tomcat 9 позволяет сохранить существующую платформу Java EE 8 в рамках её поддерживаемой ветки.
В Tomcat 10.1.61 и 11.0.27 также обновлён встроенный инструмент миграции на Jakarta EE до версии 1.0.13. Для Tomcat 9.0.x уже объявлена дата окончания поддержки — 31 марта 2027 года. При этом проект планирует продолжить развитие направления Java EE в ветке 9.1.x.
Исправление ошибки загрузки объединяет три релиза Apache Tomcat
Октябрьские версии исправляют общий дефект передачи данных, который мог проявляться при конкретном сочетании HTTP/2, TLS и асинхронного чтения. Одновременно изменения затрагивают учёт потоков HTTP/2, TLS-рукопожатия, AJP и обмен сессиями между узлами. Публичные материалы проекта не приводят статистику числа установок, столкнувшихся с повреждением загружаемых файлов, поэтому фактический масштаб проблемы по этим данным определить нельзя.
Источники
- Apache Tomcat — официальные объявления о релизах от 12 октября 2026 года
- Apache Tomcat — changelog ветки 11.0
- Apache Tomcat — changelog ветки 10.1
- Apache Tomcat — changelog ветки 9.0
- Apache Tomcat — исправление повреждения данных, pull request №1073
- Apache Tomcat — совместимость версий с Java
- Apache Tomcat — прекращение поддержки 9.0.x
