Для Apache HTTP Server опубликован proof-of-concept для уязвимости CVE-2026-49975, известной как HTTP/2 Bomb. Проблема связана с обработкой HTTP/2-запросов в mod_http2 и может привести к отказу в обслуживании из-за резкого роста потребления памяти.
Уязвимы версии Apache HTTP Server с 2.4.17 по 2.4.67. Исправление вошло в Apache HTTP Server 2.4.68. Это, по сути, DoS: атакующий не получает контроль над сервером, но может сделать сервис недоступным для нормальных пользователей.
Механика атаки строится на особенностях HTTP/2. Протокол умеет сжимать заголовки через HPACK, а сервер при обработке запроса разворачивает их в память. В случае Apache проблема проявляется при работе с множественными cookie-заголовками. Маленький сжатый запрос может заставить сервер многократно выделять память при объединении cookie.
Вторая часть атаки использует управление потоком HTTP/2. Клиент может затормозить передачу ответа так, что потоки остаются открытыми дольше обычного. Выделенная память не освобождается сразу, новые запросы продолжают добавлять нагрузку, и сервер постепенно теряет ресурс для обычной работы.
Название HTTP/2 Bomb здесь довольно точное. Входящий трафик может быть небольшим, а эффект на стороне сервера — непропорционально крупным. Это делает атаку неприятной для инфраструктуры: её можно провести без огромного ботнета, если сервер уязвим и принимает HTTP/2.
Публичный PoC выложили на GitHub. В репозитории описан тестовый стенд на Docker, где уязвимый Apache запускается с ограничением памяти, а затем демонстрируется рост потребления RAM при удержании HTTP/2-потоков. Такие публикации полезны для проверки исправлений в лаборатории, но одновременно повышают риск быстрых попыток эксплуатации на публичных серверах.
Apache Software Foundation включила CVE-2026-49975 в бюллетень по ветке 2.4 и указала, что проблема исправлена в 2.4.68. В описании уязвимости говорится о чрезмерном выделении памяти в mod_http2 через вредоносные HTTP-запросы. Автором находки указан Quang Luong из Calif.IO в сотрудничестве с OpenAI Codex.
Оценки серьезности у разных вендоров отличаются. Apache пометила проблему как moderate. Red Hat оценивает группу HTTP/2 HPACK DoS-уязвимостей как Important, потому что атака бьет по доступности сервиса и может затронуть несколько популярных серверных реализаций. Для эксплуатации не нужны учетные данные и участие пользователя, достаточно сетевого доступа к уязвимому HTTP/2-эндпоинту.
HTTP/2 Bomb не ограничивается Apache. Исследователи и поставщики упоминают похожий класс проблем для NGINX, Envoy, Microsoft IIS и Cloudflare Pingora. Реализация и исправления у каждого продукта свои, поэтому переносить выводы с Apache на другой сервер нельзя.
Для Apache главный шаг защиты — обновление до 2.4.68 или более новой версии из доверенного канала поставки. Дистрибутивы могут закрывать CVE бэкпортом без смены upstream-версии до 2.4.68, поэтому в Linux важно смотреть не только строку apache2 -v, но и бюллетень своего дистрибутива. Например, трекеры Debian отдельно показывают, какие пакеты уже исправлены в security-ветках.
Временная мера — отключить HTTP/2 там, где он не нужен. Это снижает площадь атаки, но может повлиять на производительность и поведение клиентов. Такое решение лучше применять осознанно: сначала проверить, где HTTP/2 реально включен, какие сервисы завязаны на него и нет ли перед Apache балансировщика, который уже терминирует HTTP/2.
Ограничения на размер тела запроса или отдельные лимиты заголовков сами по себе не всегда решают проблему. Суть HTTP/2 Bomb в том, что маленькие сжатые данные могут развернуться в заметные выделения памяти внутри сервера, а удержание потоков мешает быстрому освобождению ресурсов. Поэтому патч важнее настройки лимитов.
Командам эксплуатации стоит проверить наличие mod_http2, включенный Protocols h2, версии пакетов Apache, HTTP/2 на внешних виртуальных хостах, лимиты по памяти в контейнерах и поведение мониторинга при росте числа открытых HTTP/2-потоков.
Признаки атаки: растет потребление памяти процессами Apache, увеличивается число долгоживущих HTTP/2-соединений, появляются задержки ответов, пользователи видят 502/503/504 от балансировщика, контейнеры уходят в OOMKilled, а CPU при этом может не быть главным индикатором.
После обновления стоит прогнать внутренние проверки: убедиться, что внешние узлы действительно получили новый пакет, перезапустить сервисы, проверить, что старые процессы не остались в памяти, и посмотреть на метрики HTTP/2. Для крупных инсталляций полезно отдельно проверить edge-слой: CDN, WAF, балансировщики и прокси могут принимать HTTP/2 раньше, чем запрос дойдет до Apache.
Есть новость? Станьте автором.
Мы сотрудничаем с независимыми исследователями и специалистами по кибербезопасности. Отправьте нам новость или предложите статью на рассмотрение редакции.
