
Две новые уязвимости в Apache Tomcat создают риск обхода аутентификации!
Две новые уязвимости безопасности, обнаруженные в платформе Apache Tomcat, на которой работают миллионы веб-приложений по всему миру, создают серьезную угрозу для корпоративных информационных систем. Эти уязвимости, объявленные Apache Software Foundation, могут позволить обойти неправильно настроенные правила контроля доступа (Access Control) и получить несанкционированный доступ к защищенным ресурсам.
Данные уязвимости зарегистрированы под идентификаторами CVE-2026-55957 и CVE-2026-55956 и затрагивают несколько основных версий Apache Tomcat. Поэтому эксперты призывают все организации, использующие Tomcat, как можно скорее установить обновления безопасности.
Что такое Apache Tomcat?
Apache Tomcat — это один из самых популярных контейнеров сервлетов с открытым исходным кодом, предназначенный для запуска веб-приложений, созданных на языке программирования Java. Он широко используется в корпоративных информационных системах, банковских сервисах, государственных информационных ресурсах, платформах электронной коммерции и облачных сервисах.
Tomcat также выполняет важные функции безопасности, такие как аутентификация пользователей, управление сессиями и контроль доступа в веб-приложениях. Поэтому любая уязвимость в этой платформе может создать возможность несанкционированного доступа к защищенным данным.
CVE-2026-55957: Обход аутентификации через JNDIRealm
Первая обнаруженная уязвимость зарегистрирована под идентификатором CVE-2026-55957 и имеет уровень опасности Important (Важный).
Проблема наблюдается в компоненте JNDIRealm, особенно в конфигурациях, подключающихся к каталогу LDAP через аутентификацию GSSAPI.
Согласно анализу, Tomcat в некоторых случаях не полностью применяет ограничения на HTTP-методы, указанные в правилах security-constraint для Default Servlet.
В результате ограничения доступа, установленные администраторами только для определенных HTTP-методов (например, PUT, DELETE или POST), могут не учитываться.
Это позволяет злоумышленнику обращаться к защищенным ресурсам без прохождения аутентификации.
Затронутые версии
Данная уязвимость обнаружена в следующих версиях:
- Apache Tomcat 11.0.0-M1 – 11.0.4
- Apache Tomcat 10.1.0-M1 – 10.1.36
- Apache Tomcat 9.0.0.M1 – 9.0.100
Неподдерживаемые старые версии также могут быть уязвимы.
Проблема устранена, начиная с версий Tomcat 11.0.5, 10.1.37 и 9.0.101.
CVE-2026-55956: Обход защитных правил Default Servlet
Вторая уязвимость зарегистрирована под идентификатором CVE-2026-55956 и имеет уровень опасности Moderate (Средний).
Коренная причина этой уязвимости практически идентична первой.
Из-за некорректной обработки Tomcat правил <security-constraint>, установленных для Default Servlet, ограничения по HTTP-методам в некоторых случаях не применяются.
В результате ресурсы, которые должны быть закрыты только для определенных HTTP-запросов, становятся доступными через другие HTTP-методы.
Это увеличивает вероятность несанкционированного доступа к сервисам или интерфейсам управления, которые администраторы считали защищенными.
Затронутые версии
Данная уязвимость затрагивает следующие версии:
- Apache Tomcat 11.0.0-M1 – 11.0.22
- Apache Tomcat 10.1.0-M1 – 10.1.55
- Apache Tomcat 9.0.0.M1 – 9.0.118
Неподдерживаемые старые версии также могут быть под угрозой.
Проблема устранена, начиная с версий Tomcat 11.0.23, 10.1.56 и 9.0.119.
В чем суть проблемы?
Основная причина обеих уязвимостей связана с механизмом некорректного применения правил security-constraint в Tomcat.
Обычно администраторы через конфигурационный файл web.xml разрешают доступ к определенным URL или ресурсам только через некоторые HTTP-методы.
Например:
- разрешены GET-запросы;
- запрещены PUT и DELETE-запросы.
Однако из-за обнаруженной ошибки Tomcat в некоторых ситуациях не проверяет должным образом ограничения на эти методы.
В результате появляется возможность доступа к ресурсам, считавшимся защищенными, через другие HTTP-методы.
Это может привести к опасным последствиям, таким как обход механизма аутентификации, просмотр конфиденциальных данных или несанкционированное использование административных функций.
Кто подвергается наибольшему риску?
По мнению экспертов, наибольшему риску подвержены следующие среды:
- конфигурации JNDIRealm, использующие LDAP-аутентификацию;
- серверы Tomcat, интегрированные с Active Directory или LDAP через GSSAPI;
- системы, где панель администратора или API-сервисы работают через Default Servlet;
- серверы Tomcat, доступные из Интернета;
- корпоративные Java-приложения, работающие на старых версиях.
Если на этих серверах применяется контроль доступа на основе методов, уязвимость может быть успешно использована.
Рекомендации по защите
Apache Software Foundation сообщила, что для данных уязвимостей не существует временных обходных решений.
Поэтому единственным надежным решением является переход на обновленные версии.
Эксперты рекомендуют следующие меры:
- как можно скорее обновить Apache Tomcat до версий с установленными исправлениями безопасности;
- после обновления проверить правила security-constraint в файле web.xml;
- протестировать, правильно ли работают ограничения по HTTP-методам;
- не оставлять административные интерфейсы и важные API-сервисы в открытом доступе из Интернета;
- провести аудит конфигураций аутентификации LDAP и Active Directory;
- мониторить необычные HTTP-запросы с помощью WAF, SIEM и EDR-систем;
- регулярно проверять правила контроля доступа с помощью тестов безопасности и пентестов.
Заключение
Уязвимости CVE-2026-55957 и CVE-2026-55956 еще раз продемонстрировали, насколько серьезную угрозу для крупных корпоративных систем могут представлять даже, казалось бы, незначительные ошибки в механизмах контроля доступа. Особенно когда правила аутентификации и авторизации работают некорректно, злоумышленники могут получить несанкционированный доступ к ресурсам, считавшимся защищенными.
Поскольку Apache Tomcat является одной из наиболее широко используемых Java-веб-платформ в мире, своевременное устранение данных уязвимостей является приоритетной задачей для каждой организации. Администраторам рекомендуется перевести серверы на обновленные версии, провести повторный аудит политик контроля доступа и с помощью практических тестов убедиться в корректной работе правил безопасности, основанных на HTTP-методах.



