CVE-2025-24813
Tomcat: когда частичная загрузка файлов становится опасной
Ошибка обработки partial PUT в Tomcat могла раскрывать или изменять файлы, а при дополнительных условиях — выполнять код. Проверьте разрешение записи Default Servlet, хранение сеансов и версию сервера.
Кому нужно проверить
Администраторам Java-сайтов и приложений на Tomcat, особенно с загрузкой файлов и сохранением сеансов на диск. Проверять нужно также Tomcat, встроенный в приложение или образ поставщика. Важна не только марка продукта, но и конкретная версия, способ установки, операционная система и конфигурация.
В чём риск
Partial PUT позволяет передавать файл частями. Уязвимая реализация создавала временное имя из пути пользователя, заменяя разделители точками. Разные пути могли оказаться эквивалентны. В одних настройках это открывало доступ к чужим загрузкам, в других затрагивало файлы сеансов. Десериализация — восстановление объектов из сохранённых данных; при подходящей библиотеке подмена таких данных может привести к выполнению кода. Эти сценарии имеют разные предпосылки, и их нельзя объединять в утверждение о безусловном захвате сервера.
Затронутые версии
Tomcat 9.0.0.M1–9.0.98, 10.1.0-M1–10.1.34 и 11.0.0-M1–11.0.2. Запись CVE также подтверждает затронутую завершившую поддержку ветку 8.5.0–8.5.100. Для описанных атак нужны разрешённая запись Default Servlet (по умолчанию выключена) и partial PUT (по умолчанию включён). Для раскрытия или изменения файлов дополнительно нужны вложенность адреса защищённых загрузок в адрес публичных, знание имён защищённых файлов и загрузка этих файлов через partial PUT. Для выполнения кода нужны файловое сохранение сеансов Tomcat в стандартном месте и библиотека приложения, пригодная для атаки десериализации. Для прочих старых веток не следует угадывать применимость.
Исправленные версии
Первые исправленные выпуски: 9.0.99, 10.1.35 и 11.0.3. Для 8.5 нужен переход с неподдерживаемой ветки. Выбирайте актуальный поддерживаемый выпуск, совместимый с Java и приложением; переход между основными ветками может потребовать адаптации приложения.
Что сделать
- 1Определите фактическую версию Tomcat во всех экземплярах и встроенных зависимостях. Попросите администратора проверить эффективные настройки Default Servlet, а не только один web.xml: приложение может переопределять общую конфигурацию.
- 2Уточните, включена ли запись, используется ли partial PUT и где сохраняются сеансы. Для сценария раскрытия файлов проверьте структуру URL загрузок; для выполнения кода — файловое сохранение сеансов и библиотеки. Не загружайте специально составленные файлы на рабочий сайт.
- 3До обновления отключите ненужную запись через Default Servlet либо partial PUT, предварительно проверив влияние на загрузки. Ограничьте доступ к затронутым функциям. Фильтр на прокси должен охватывать все входы; он не исправляет Tomcat.
- 4Сохраните конфигурацию, приложения и данные загрузок. Проверьте резервное восстановление. На тестовой копии обновите Tomcat и проверьте вход, сохранение сеансов, обычные загрузки и скачивание с нужными правами.
- 5Разверните исправленный поддерживаемый выпуск на всех экземплярах и подтвердите версию работающего процесса. При откате сохраняйте отключение опасной функции или ограничение доступа; учитывайте совместимость Java, приложения и сохранённых сеансов.
- 6Проверьте журналы загрузок и изменения файлов за период риска. Если есть признаки подмены или исполнения кода, сохраните доказательства и начните разбор инцидента: одно обновление не удаляет уже внесённые изменения. Универсальная команда настройки не приводится, поскольку конфигурация встроенного и отдельного Tomcat различается.
Проверка условий по порядку
Статичный список отделяет общие условия от двух разных последствий. Для понимания не нужны цвет, анимация или указатель мыши.
- 1Установлена затронутая версия Tomcat
- 2Разрешены запись Default Servlet и partial PUT
- 3Для файлов: проверяются адреса загрузок, имена и способ передачи
- 4Для выполнения кода: отдельно проверяются сеансы и библиотеки
- 5Обновление устраняет ошибку независимо от выбранного сценария
Как не подпустить ботов к сайту
BotProtection принимает запросы перед вашим сайтом и фильтрует автоматизированные обращения. Поэтому ботам сложнее добраться до уязвимого компонента и начать его проверять или атаковать, а вероятность успешной автоматизированной атаки становится значительно ниже. Это дополнительный слой защиты: обновление уязвимых компонентов, проверка журналов и реагирование на инциденты остаются обязательными.
Первоисточники
Снизьте шанс атаки до того, как бот дойдёт до сайта
Подключите BotProtection как фильтр перед сайтом: подозрительные автоматизированные запросы отсекаются до обращения к вашему серверу. Это значительно снижает вероятность автоматизированной атаки, но не исправляет саму уязвимость, поэтому обновление и настройка компонентов остаются обязательными.