Исследователи опубликовали код доказательства эксплуатации (proof-of-concept, PoC) и технические детали уязвимости, которая позволяет удалённо выполнять код без аутентификации в некоторых конфигурациях Apache Tomcat. Речь идёт о проблеме CVE-2026-34486, получившей высокий уровень опасности (7,5 балла по шкале CVSS v3.1). Под удар попали версии 9.0.116, 10.1.53 и 11.0.20 популярного сервера приложений.
Уязвимость CVE-2026-34486
Apache Tomcat - это широко используемый контейнер сервлетов Java с открытым исходным кодом. С его помощью организации запускают веб-приложения и API. В кластерных средах Tomcat применяет компонент Tribes для репликации данных сессий между узлами. Для шифрования межсерверной связи используется EncryptInterceptor - перехватчик, обеспечивающий защиту канала.
Откуда взялась уязвимость? Всё началось с исправления другой проблемы - CVE-2026-29146. Разработчики изменили логику обработки ошибок шифрования, но допустили регрессию, то есть внесли новый дефект. В результате система перестала отклонять сообщения, которые не удалось расшифровать. Вместо этого она продолжала передавать их дальше по цепочке обработки.
Это значит, что злоумышленник может отправить на кластерный порт Tomcat специально сформированный пакет, который не прошёл расшифровку, но всё равно будет принят. Тем самым атакующий обходит механизмы шифрования, защищающие трафик между узлами. Данные, которые должны оставаться зашифрованными, становятся доступными для манипуляции.
Опасность усугубляется тем, что при доступности канала связи Tribes уязвимость можно скомбинировать с поведением десериализации Java. Это позволяет выполнять код удалённо без всякой аутентификации. Достаточно отправить на порт приёмника кластера вредоносную полезную нагрузку (payload), которая сработает при десериализации.
Разработчики выпустили исправленные версии 4 апреля 2026 года. Это Apache Tomcat 9.0.117, 10.1.54 и 11.0.21. Обновление корректирует логику обработки сообщений и восстанавливает проверку шифрования.
Условия, необходимые для атаки, довольно специфичны. Во-первых, должна быть включена кластеризация Tomcat. Во-вторых, приёмник Tribes должен быть достижим по сети - обычно это TCP-порт 4000. В-третьих, используется EncryptInterceptor. И в-четвёртых, на classpath сервера должны присутствовать уязвимые библиотеки для десериализации. Если хотя бы одно из условий не выполняется, удалённое выполнение кода становится невозможным, хотя сама брешь в обработке сообщений никуда не девается.
Как оценить реальную угрозу? Степень риска напрямую зависит от архитектуры развёртывания. Если кластеризация включена, а порт связи Tribes открыт наружу, вероятность атаки из интернета резко возрастает. Если же кластеризация отключена или порт изолирован во внутренней сети, доступ злоумышленника ограничен локальными каналами.
Обновление до патченных версий полностью устраняет уязвимый участок кода. Это касается всех моделей развёртывания. Кроме того, администраторам стоит проверить конфигурацию: определить, используется ли кластеризация и достижим ли порт 4000. Если кластеризация не требуется, её лучше отключить - тогда уязвимый компонент вообще не будет задействован. Также стоит ограничить доступ к порту обмена данными кластера, чтобы снизить вероятность атаки извне.
Эксперты подчёркивают, что, хотя для успешной атаки нужно несколько условий, их одновременное выполнение не редкость в корпоративных средах. Многие организации используют кластеризованные Tomcat-инсталляции с шифрованием канала и популярными библиотеками десериализации вроде Apache Commons Collections. Анализ открытых данных показывает, что такие конфигурации встречаются в финансовом секторе, электронной коммерции и государственных информационных системах.
Учитывая, что код эксплуатации уже опубликован, компаниям следует как можно быстрее установить обновления Apache Tomcat. Альтернативное решение - временно отключить кластеризацию или изолировать порт 4000 с помощью правил межсетевого экрана. Однако эти меры лишь уменьшают поверхность атаки, но не исправляют саму уязвимость.
Важно помнить: CVE-2026-34486 - результат неудачного исправления другой проблемы. Это напоминание о том, что каждое изменение кода требует тщательного тестирования, особенно когда речь идёт о безопасности. Разработчикам следует внедрять регрессионные тесты для критических компонентов вроде обработки шифрованных сообщений.
Для специалистов по информационной безопасности ситуация с этой уязвимостью стала очередным сигналом: нельзя полагаться только на защиту периметра. Даже если кластерный порт не доступен из интернета, внутренний злоумышленник, получивший доступ к сети предприятия, может использовать эту брешь для движения вглубь инфраструктуры. Поэтому обновления нужно применять вне зависимости от того, кажется ли контур изолированным.
Таким образом, ключевая рекомендация - установить исправленные версии Apache Tomcat 9.0.117, 10.1.54 или 11.0.21. До выполнения патча стоит проверить, включена ли кластеризация, и принять меры по ограничению доступа к порту 4000. Игнорирование проблемы может привести к полному захвату сервера злоумышленником без каких-либо учётных данных.
Ссылки
- https://github.com/striga-ai/CVE-2026-34486
- https://www.cve.org/CVERecord?id=CVE-2026-34486
- https://lists.apache.org/thread/9510k5p5zdvt9pkkgtyp85mvwxo2qrly
- https://fieldeffect.com/blog/public-exploit-code-apache-tomcat-flaw
- https://www.vicarius.io/vsociety/posts/cve-2026-34486-detection-script-rce-on-apache-tomcat
- https://www.vicarius.io/vsociety/posts/cve-2026-34486-mitigation-script-rce-on-apache-tomcat
