Критическая уязвимость DoS в Apache Struts 2
Apache Software Foundation раскрыла две связанные критические уязвимости типа Denial of Service, затрагивающие практически все версии фреймворка Apache Struts. Эти уязвимости позволяют неаутентифицированным злоумышленникам исчерпать дисковое пространство сервера посредством специально сформированных запросов загрузки файлов, что может привести к полной недоступности системы. Организации, использующие Apache Struts, должны немедленно принять меры для оценки своего риска и реализации мер по устранению угрозы.
Apache Struts 2 — один из наиболее популярных Java-фреймворков для создания веб-приложений — оказался уязвим к сложной атаке типа Denial of Service. Уязвимости, отслеживаемые как CVE-2025-64775 и CVE-2025-66675, связаны с некорректной обработкой multipart-запросов: механизм загрузки файлов создает временные файлы, но не удаляет их после обработки.
Когда злоумышленник отправляет специально сформированные multipart-запросы (с загрузкой файлов или с большими полями формы), Apache Struts создает временные файлы на локальной файловой системе сервера. Из-за дефекта в процессе очистки класса JakartaMultiPartRequest, эти временные файлы не удаляются. Они накапливаются, занимают всё доступное дисковое пространство, приводя к постепенной деградации работоспособности, а затем — к полной остановке сервера.
Когда диск переполняется, система теряет возможность:
— записывать данные,
— формировать новые логи,
— обслуживать сессии,
— выполнять критические операции ввода-вывода.
Это приводит к полной недоступности сервисов и требует ручного вмешательства. 2.3.x и 2.5.x — они больше не поддерживаются и не получают исправлений безопасности.
Масштаб воздействия
Затронуты версии:
- Apache Struts 2.0.0 — 6.7.4
- Apache Struts 7.0.0 — 7.0.3
Почти все организации, использующие Struts, попадают в зону риска.
Наибольшую угрозу несут устаревшие внедрения Struts 2.3.x и 2.5.x, которые не поддерживаются и больше не получают патчи безопасности. Они содержат не только описанные уязвимости, но и целый набор иных критических дефектов.
Детали уязвимости и технический анализ
Понимание CVE-2025-64775 и CVE-2025-66675
Оба CVE описывают разные аспекты одной и той же фундаментальной проблемы — утечки файлов из multipart-обработчика Struts.
- CVE-2025-64775 — первичное раскрытие (1 декабря 2025)
- CVE-2025-66675 — расширение и исправление диапазона затронутых версий (10 декабря 2025), включая 6.7.4
Таблица различий
| Атрибут | CVE-2025-64775 | CVE-2025-66675 |
|---|---|---|
| Дата публикации | 1 декабря 2025 | 10 декабря 2025 |
| Базовый CVSS | 7.5 (High) | 8.2 (High) |
| Вектор CVSS | AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H | AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H |
| Требуемые привилегии | Нет | Нет |
| Пользовательское взаимодействие | Не требуется | Не требуется |
| Влияние на доступность | Высокое | Высокое |
| Затронутые версии | 2.0.0–6.7.0; 7.0.0–7.0.3 | 2.0.0–6.7.4; 7.0.0–7.0.3 |
| Связь | Первичное описание | Исправление диапазона версий |
Почему два CVE?
Потому что исходная заявка не включала версию 6.7.4, которая также оказалась уязвимой. Второе CVE расширяет и уточняет охват уязвимости.
Первопричина — утечка файлов в JakartaMultiPartRequest
Уязвимость возникает в классе:
org.apache.struts2.dispatcher.multipart.JakartaMultiPartRequest
Особенно — в методе cleanUp(), который должен удалять временные файлы, созданные в процессе обработки multipart-запросов.
Но реализация удаляет только файлы, связанные с фактической загрузкой файлов, игнорируя временные файлы, созданные для обычных полей формы, если они превышают допустимый порог размера.
Таблица компонентов
| Компонент | Функция | Уязвимость | Последствие |
|---|---|---|---|
| JakartaMultiPartRequest | Обработка multipart/form-data | Неполная очистка | Временные файлы накапливаются |
| Apache Commons FileUpload | Низкоуровневая обработка файлов | Создает временные файлы | Множество файлов на один запрос |
| cleanUp() | Очистка после запроса | Пропускает formFields | Утечка файлов |
| processUpload() | Разбор запроса | Создает временные объекты без гарантий удаления | Осиротевшие файлы |
| Файловая система | Хранение tmp-файлов | Нет автоудаления | Постепенная потеря диска |
Пример уязвимого шаблона кода
public void cleanUp() {
for (FileItem item : fileItems) {
if (item.isFormField()) {
// ОШИБКА: временные файлы для больших полей формы не удаляются
continue;
}
item.delete(); // удаляет только файлы загрузки
}
}
Каждый multipart-запрос может оставлять мусорные временные файлы.
Многократные запросы → лавинообразное накопление файлов → исчерпание носителя.
Механика атаки и сценарий эксплуатации
Усложнённости минимальны — это делает DoS особенно опасным.
Сценарий атаки
| Фаза | Действие злоумышленника | Реакция системы | Итог |
|---|---|---|---|
| 1. Разведка | Определяет Struts-приложение | Нормальная обработка | Выбор цели |
| 2. Первое зондирование | Отправляет большой multipart-запрос | Создаются временные файлы | Начало утечки |
| 3. Масштабирование | Автоматизирует запросы | Быстрое накопление мусора | Рост использования диска |
| 4. Насыщение | Увеличивает нагрузку | Ошибки I/O | Приложение начинает тормозить |
| 5. DoS | Заполняет диск | Невозможность записей | Полный отказ |
| 6. После атаки | Атака прекращена | Мусор остаётся | Восстановление вручную |
Низкий барьер эксплуатации
Не требуется:
- аутентификация,
- привилегии,
- социальная инженерия,
- взаимодействие пользователя.
Используются обычные инструменты:
- curl
- Python-скрипты
- Burp Intruder
- любой HTTP-генератор
Оценка воздействия и рисков
Последствия затрагивают практически все аспекты ИТ-операций:
| Категория | Немедленные эффекты | Среднесрочные последствия | Долгосрочные риски |
|---|---|---|---|
| Доступность | Полный простой | Снижение качества обслуживания | Потеря клиентов |
| Данные | Ошибки записи, повреждение журналов | Несогласованность данных | Аудиторские нарушения |
| Операции | Нет логирования, нет мониторинга | Пропуск инцидентов | Уязвимость к последующим атакам |
| Финансы | Потери доходов | Штрафы SLA | Увеличение стоимости страхования |
| Репутация | Жалобы | Негатив в СМИ | Долговременный ущерб бренду |
| Восстановление | Очистка файлов | Перезапуск сервисов | Архитектурные улучшения |
Отраслевые факторы риска
Разные индустрии испытывают различную степень воздействия, исходя из зависимости от Struts и чувствительности к простоям.
| Отрасль | Использование Struts | Риск | Ключевые угрозы |
|---|---|---|---|
| Финансовые услуги | Широко используется в старых банковских системах и платёжных шлюзах | Критический | Сбои транзакций, нарушение отчётности, блокировка счётов |
| E-commerce | Часто используется в системах управления заказами и складом | Высокий | Потеря продаж, отказ корзины, ошибки оплаты |
| Здравоохранение | Порталы пациентов, EMR-системы | Критический | Нарушение ухода, недоступность карточек, сбои записи пациентов |
| Государственный сектор | Налоговые сервисы, порталы госуслуг | Высокий | Простой критических сервисов, задержка государственных процессов |
| Образование | Порталы студентов, LMS | Средний | Недоступность курсов, сбои оценивания |
| Телеком | Биллинг, CRM | Высокий | Сбои тарификации, снижение качества поддержки |
| Производство | SCM, системы контроля качества | Средний | Сбои поставок, ошибки учёта, проблемы у поставщиков |
Стратегии обнаружения и идентификации уязвимости
Методология оценки уязвимостей
Организация должна оперативно определить:
- есть ли Struts-приложения в среде,
- какие из них используют уязвимые версии,
- являются ли они доступными из интернета,
- содержат ли функциональность загрузки файлов или больших форм.
Таблица процесса оценки
| Фаза | Действия | Инструменты / методы | Результат |
|---|---|---|---|
| Инвентаризация | Найти все Java-веб-приложения | CMDB, сетевые сканеры, кодовые репозитории | Полный список |
| Определение версии Struts | Проверить jar-файлы, зависимости | unzip, grep, Maven/Gradle | Классификация по версиям |
| Анализ подверженности | Проверить доступность извне и поверхность атаки | Анализ архитектуры, FW-правила | Приоритет патчинга |
| Анализ функциональности | Проверить наличие multipart-загрузок | Код-ревью, тестирование, документация | Подтверждение риска |
| Оценка критичности | Оценить бизнес-воздействие | SLA, BIA, карта зависимостей | Приоритет работ |
| Соответствие требованиям | Учесть регуляторные требования | PCI DSS, HIPAA, ISO | Сроки патчинга |
Команды для обнаружения уязвимых версий
Проверка jar-файла:
jar -tf application.war | grep struts2-core
unzip -l application.war | grep struts2-core
Maven:
mvn dependency:tree | grep struts
Поиск библиотек Struts:
find / -name "struts2-core*.jar" 2>/dev/null
Проверка запущенных процессов:
ps aux | grep java
jps -v | grep struts
Проверка зависимостей в web-приложении:
ls -la WEB-INF/lib/ | grep struts
Мониторинг и обнаружение атак
Даже до патча необходимо развернуть мониторинг на уровне инфраструктуры и приложения.
Что нужно отслеживать
| Объект мониторинга | Что считать подозрительным | Методы | Реакция |
|---|---|---|---|
| Дисковое пространство | Быстрый рост использования | Grafana, Zabbix, df-alerts | Экстренная очистка |
| Каталоги tmp | Массовое появление файлов | du, inodes monitoring | Анализ источников |
| Multipart-трафик | Большое число POST multipart | access-logs, WAF | Ограничение/блокировка |
| Ошибки приложения | Ошибки I/O, невозможность записи | APM, логи | Срочное расширение диска |
| Система логирования | Пропуск записей, ошибки ротации | Syslog, SIEM | Временное увеличение места |
| Производительность | Деградация I/O, задержки | APM | Переключение на резерв |
Примеры команд для мониторинга
Уровень диска:
df -h
watch -n 5 'df -h | grep -E "/tmp|/var"'
Поиск временных файлов:
du -sh /tmp /var/tmp
find /tmp -type f -mtime -1 | wc -l
find /tmp -name "*.tmp" -o -name "struts*" -o -name "upload_*"
Логи HTTP:
grep -i "multipart" /var/log/apache2/access.log | tail -100
Стратегии устранения и смягчения (Remediation & Mitigation)
Требования немедленного патчинга
Apache Foundation выпустила исправления:
| Версии | Статус | Действие | Целевая версия |
|---|---|---|---|
| 2.0.0–6.7.4 | Уязвимы | Срочно обновить | 6.8.0+ |
| 7.0.0–7.0.3 | Уязвимы | Срочно обновить | 7.1.1+ |
| 2.3.x / 2.5.x | Уязвимы, не поддерживаются | Миграция обязательна | 6.8.0 или 7.1.1 |
Почему особенно опасны старые версии?
- нет патчей
- устаревший код
- известные эксплуатационные цепочки
- легко автоматизируемые атаки
Поэтапное внедрение патчей
| Фаза | Срок | Действия | Результат |
|---|---|---|---|
| Экстренная (0–24ч) | Немедленно | WAF, rate-limit, мониторинг | Временная защита |
| Критичные системы (1–7 дней) | Приоритет | Обновить внешние и бизнес-критичные сервисы | Уменьшение риска |
| Остальные системы (1–4 недели) | Планово | Обновить оставшиеся приложения | Полная защита |
| Dev/Test среды (1–8 недель) | Планово | Обновить CI/CD | Избежание повторного внедрения |
| Устаревшие системы (2–6 месяцев) | Стратегически | Миграция на поддерживаемые версии | Снижение долговременного риска |
Компенсирующие меры (если патч невозможен)
| Контроль | Эффективность | Ограничения |
|---|---|---|
| WAF (multipart rules) | Средняя | Можно обойти |
| Rate limiting POST multipart | Средняя | Замедляет, но не предотвращает |
| Дисковые квоты | Низкая | Может ломать функциональность |
| Сегментация сети | Высокая | Не устраняет уязвимость |
| Cron-очистка tmp | Низкая | Симптом, не решение |
| Мониторинг диска в реальном времени | Высокая | Реактивно |
| Geo-блокировки | Низкая | VPN обход |
Важно: Единственное исправление — обновление Struts.
Обнаружение и подтверждение атаки
Если организация подозревает, что уязвимость уже эксплуатируется, необходимо быстро подтвердить факт атаки и оценить масштаб ущерба. Основной индикатор — аномальный рост количества временных файлов и быстрое заполнение дискового пространства.
Команды для быстрой диагностики
1. Проверить дисковое пространство:
df -h
du -sh /tmp /var/tmp /upload-directory
2. Найти утекшие временные файлы:
find /tmp -name "upload_*" -o -name "struts*" -o -name "*.tmp"
ls -lah /tmp | grep $(date +%Y-%m-%d)
3. Найти подозрительные multipart-запросы в HTTP-логах:
grep -i "multipart" /var/log/apache2/access.log | tail -100
grep -i "Content-Type: multipart" /var/log/httpd/access_log
4. Мониторинг использования диска в реальном времени:
watch -n 5 'df -h | grep -E "/tmp|/var"'
5. Определить процессы, удерживающие удалённые файлы (часто признак DoS):
lsof +L1 | grep deleted
Этапы реагирования на инцидент
Организация должна применять системный и документированный подход.
1. Изоляция поражённых систем
Цель: предотвратить дальнейшую эксплуатацию и остановить рост временных файлов.
Действия:
- заблокировать входящий трафик на уязвимое приложение;
- отключить внешние интерфейсы;
- запретить доступ злоумышленнику к сервису упреждающе;
- сохранить форензические артефакты до вмешательства.
Важно:
Это может привести к простою, поэтому решение требует согласования с бизнесом.
2. Очистка временных файлов и восстановление дискового пространства
Действия:
- идентифицировать временные файлы по маске (
upload_*,*.tmp,struts*); - сохранить образцы для анализа;
- удалить лишние файлы вручную или автоматизированно;
- временно расширить объём хранилища (LVM resize / cloud volume extend).
Риски:
- возможное удаление файлов, которые приложение ещё использует.
3. Развертывание экстренных WAF-правил
Правила могут включать:
- блокировку multipart-запросов большого размера,
- ограничение скорости POST-запросов,
- блокировку подозрительных IP, генерирующих аномальный трафик.
Недостаток:
WAF — это временная защита, не исправление.
4. Сбор криминалистических данных
Потребуется, если возможна юридическая, регуляторная или внутренняя проверка.
Необходимо сохранить:
- журналы HTTP-доступа (до очистки),
- системные логи,
- содержимое временных файлов (образцы),
- снимки дисков,
- сетевые дампы.
Обоснование:
- помогает определить источник атаки,
- подтверждает или исключает утечку данных,
- позволяет скорректировать меры защиты.
5. Уведомление заинтересованных сторон
Это шаг организационного уровня:
- уведомить руководителей ИБ и ИТ,
- сообщить владельцам бизнес-процессов,
- уведомить клиентов (если требуется регуляторикой),
- подготовить внешнее заявление при длительном простое.
6. Экстренный патчинг
Если эксплуатация подтверждена — откладывать обновление Struts нельзя.
Требования:
- внеплановое окно изменений,
- тестирование основных функций,
- проверка безопасности после обновления.
Форензика и анализ инцидента
Цели форензики:
- Определить источник атаки.
- Установить временную шкалу.
- Выявить потенциально украденные данные.
- Установить повторяющиеся паттерны запросов.
- Проверить, не внедрены ли закладки или бэкдоры.
Ключевые артефакты:
| Тип | Что искать |
|---|---|
| access.log | Большой объём multipart POST, одинаковые IP, повторяющиеся шаблоны |
| error.log | I/O ошибки, невозможность записи журналов |
| /tmp | Внезапный рост числа файлов |
| inode usage | Переполнение inode при небольшом размере файлов |
| Системные логи | Предупреждения о нехватке диска |
Процедуры восстановления
После остановки атаки и очистки диска — нужно корректно восстановить систему.
1. Проверка целостности данных
Потому что:
- база могла записать неполные или повреждённые транзакции,
- журналы транзакций могли быть нарушены,
- резервные копии могли не создаться из-за отсутствия места.
Проверить:
- транзакционные логи,
- очереди сообщений,
- работу фоновых задач,
- историю ошибок приложений.
2. Перезапуск сервисов
После восстановления пространства многие сервисы не восстановятся автоматически.
Требуется:
- перезапуск Java-приложений,
- перезапуск контейнеров,
- пересборка индексов (если требовалось),
- проверка работоспособности Nginx / Apache.
3. Перепроверка мониторинга
Необходимо подтвердить:
- восстановлена ли ротация логов,
- корректно ли работает сбор метрик,
- восстановились ли алертинг и уведомления.
Долгосрочные улучшения безопасности
Уязвимость Struts показала слабые места не только в приложениях, но и в процессах.
1. Улучшение управления уязвимостями
Проблема: реактивный подход, патчи не ставятся вовремя.
Решение:
- определить SLA для критических патчей (1–3 дня),
- автоматизировать сканирование уязвимостей,
- еженедельно анализировать зависимость Struts во всех проектах.
2. Улучшение отслеживания зависимостей
Проблема: команда не знает, где используется какая версия Struts.
Решение:
- внедрить Software Bill of Materials (SBOM),
- интегрировать dependency-check в CI/CD,
- автоматически блокировать деплой уязвимых версий.
3. Интеграция тестов безопасности
Включить в CI/CD:
- SAST,
- DAST,
- зависимости-проверки,
- тесты на DoS.
4. Управление фреймворками
Проблема: разные версии Struts в разных сервисах.
Решение:
- создать корпоративный стандарт версий,
- запретить деплой устаревших библиотек.
5. Управление устаревшими системами
Это главная проблема, ведущая к атакам.
Решение:
- определить все 2.3.x и 2.5.x,
- составить план миграции,
- назначить ответственных за модернизацию.
6. Улучшение мониторинга
Мониторинг должен быть:
- многоуровневым (диск, приложение, сеть),
- с порогами и алертами,
- интегрирован в SIEM.
Построение устойчивых практик безопасности
Инцидент с уязвимостью Apache Struts наглядно демонстрирует критическую необходимость проактивного и зрелого управления безопасностью. Даже один пропущенный патч или недосмотр в обработке multipart-запросов способен привести к полному отказу сервисов, нарушению бизнеса, финансовым потерям и серьёзным репутационным рискам.
Организации, которые:
- поддерживают актуальные версии фреймворков,
- регулярно проводят комплексный мониторинг,
- оперативно внедряют исправления,
- проводят аудиты зависимостей,
- интегрируют тестирование безопасности в CI/CD,
— значительно снижают вероятность подобных инцидентов.
Инвестиции в зрелость процессов безопасности превращают инфраструктуру из реактивной в проактивную, позволяя предотвращать атаки ещё до их начала.
Улучшение процессов и архитектуры (долгосрочная стратегия)
Восстановление после инцидента — это не просто решение текущей проблемы. Это возможность усовершенствовать архитектуру и процессы, чтобы подобные уязвимости в будущем не представляли угрозы.
Ниже — ключевые направления улучшений.
1. Управление уязвимостями (Vulnerability Management)
Проблема: критические версии фреймворков оставались без патчей слишком долго.
Решение:
- формализовать SLA для критических обновлений: 1–3 дня;
- автоматизировать сканирование уязвимостей (Nessus, Qualys, OpenVAS);
- ежемесячно проводить ревизию зависимостей.
2. Контроль зависимостей (Dependency Governance)
Проблема: команды не владеют информацией о версиях Struts во всех приложениях.
Решение:
- внедрить SBOM (Software Bill of Materials);
- автоматизировать проверку зависимостей в CI/CD;
- внедрить политики блокировки уязвимых версий при сборке.
3. Интеграция тестирования безопасности
В каждом релизе должны выполняться:
- SAST (статический анализ кода),
- DAST (динамический анализ),
- Dependency Check,
- нагрузочные тесты на multipart и DoS-чувствительные узлы.
4. Стандартизация фреймворков
Проблема: разные приложения использовали разбросанные версии Struts.
Решение:
- создать внутренний список разрешённых версий;
- описать процесс обновления;
- запретить деплой устаревших библиотек.
5. Управление устаревшими системами (Legacy Management)
Самый критичный фактор риска — существование версий 2.3.x и 2.5.x в проде.
Решение:
- создать план миграции,
- разработать политики end-of-life,
- выделить бюджет на модернизацию приложений.
6. Мониторинг и наблюдаемость
Стратегия мониторинга должна включать:
- отслеживание использования диска,
- мониторинг числа файлов в /tmp,
- WAF-аналитику по multipart-запросам,
- алерты по отклонениям I/O,
- интеграцию в SIEM с корреляцией событий.
Заключение и ключевые выводы
Уязвимости CVE-2025-64775 и CVE-2025-66675 представляют собой серьёзные DoS-проблемы, поражающие один из наиболее распространённых Java-фреймворков — Apache Struts. Ошибка в обработке multipart-запросов приводит к утечке временных файлов, которые не очищаются системой, постепенно заполняя дисковое пространство, вплоть до полного отказа работы приложений.
Почему эти уязвимости критичны:
- эксплуатируются удалённо и без аутентификации;
- требуют минимальных усилий для атаки;
- воздействие — полный отказ сервиса;
- затрагивают огромный диапазон версий;
- легко автоматизируются;
- атаки трудно обнаружить до начала деградации системы.
Организациям необходимо:
- Немедленно обновиться до Struts 6.8.0+ или 7.1.1+.
- Внедрить временные меры защиты — WAF, rate limiting, мониторинг.
- Провести полную инвентаризацию приложений.
- Удалить устаревшие версии Struts из продакшена.
- Настроить непрерывное наблюдение за диском, multipart-трафиком и логами.
- Реализовать долгосрочную программу улучшений безопасности.
Стратегический вывод
Эта уязвимость — напоминание о том, что безопасность веб-приложений определяется не только качеством кода, но и зрело выстроенными процессами:
- управления уязвимостями,
- управления зависимостями,
- мониторинга,
- CI/CD контролей,
- архитектурных стандартов.
Организации, которые используют инцидент как стимул модернизировать эти процессы, смогут значительно снизить риски будущих атак и обеспечить устойчивость своих приложений.