Один клиент с каналом 100 Мбит/с может уронить уязвимый веб-сервер меньше чем за минуту и удерживать занятыми десятки гигабайт памяти. Именно так работает HTTP/2 Bomb — новая DoS-атака, которая бьет по типовым конфигурациям NGINX, Apache httpd, Microsoft IIS, Envoy и Cloudflare Pingora и выглядит неприятно именно для тех, кто привык считать одиночного клиента шумом, а не угрозой.
Об атаке сообщает BleepingComputer. Технику описали исследователи offensive security-компании Calif; в публикации сказано, что уязвимость была обнаружена агентом Codex от OpenAI под руководством команды исследователей. Суть не в какой-то экзотической дыре в одном продукте, а в довольно приземленной комбинации двух уже известных приемов внутри HTTP/2: усиления через HPACK-сжатие заголовков и удержания ресурсов по схеме Slowloris, только адаптированной под flow control протокола.
На практике картина выглядит так. Атакующий добавляет заголовок в динамическую таблицу HPACK, а затем многократно ссылается на него в компактной индексной форме, которая может занимать всего один байт. Для сервера это не один байт, а выделение памяти под внутреннюю обработку заголовков. По данным исследователей, в худших случаях коэффициент усиления доходит до 5700:1 у Envoy и до 4000:1 у Apache httpd. То есть атакующий отправляет крошечный объем данных, а сервер в ответ сам загоняет себя в дефицит памяти.
Если бы на этом все заканчивалось, история была бы неприятной, но не особенно новой. Вторая часть атаки делает ее заметно злее: клиент объявляет нулевое окно flow control и не дает серверу нормально завершить передачу ответа. Сервер продолжает держать выделенные ресурсы и периодически отправляет небольшие WINDOW_UPDATE-фреймы, чтобы не словить тайм-аут. Иными словами, память не просто быстро расходуется, а еще и не освобождается. Исследователи отдельно подчеркивают, что этот сценарий обходит типовые защиты, завязанные на ограничение общего размера декодированных заголовков: значения заголовков сами по себе крошечные, а проблема возникает из-за внутренних накладных расходов и структуры аллокаций.
Цифры у атаки не академические. В тестах Calif сервер Envoy 1.37.2 исчерпал 32 ГБ оперативной памяти примерно за 10 секунд. Apache httpd 2.4.67 дошел до тех же 32 ГБ примерно за 18 секунд. NGINX 1.29.7 продержался около 45 секунд до заполнения 32 ГБ, а IIS на Windows Server 2025 за те же примерно 45 секунд выбрал 64 ГБ. На языке эксплуатации это означает простую вещь: для заметного эффекта не нужен ботнет, аренда облака или гора трафика. Достаточно одной машины и аккуратно собранного сценария атаки.
Для инфраструктурных команд здесь особенно неприятен именно разрыв между внешней видимостью и внутренним эффектом. Трафика может быть не так много, заголовки маленькие, а поведение на сетевом уровне поначалу не выглядит как классический ковровый DoS с валом запросов. Это уже не история про “добавим rate limiting и переживем”, а история про то, что сервер сам честно резервирует память в ответ на формально корректные HTTP/2-механизмы. Поэтому под ударом оказываются не только публичные сайты, но и API-шлюзы, внутренние панели, сервисы за балансировщиками и другие точки, где HTTP/2 включен по умолчанию просто потому, что так удобнее и быстрее.
Хорошая новость в том, что проблема не везде остается без ответа. Для NGINX исправление уже вышло в версии 1.29.8, где добавлена директива max_headers. В Apache httpd исправление появилось в mod_http2 2.0.41; проблеме присвоен идентификатор CVE-2026-49975. Плохая новость тоже довольно прямолинейна: на момент публикации патчей для IIS, Envoy и Pingora еще нет. Для таких платформ рекомендация скучная, но рабочая: где возможно, отключать HTTP/2, а перед уязвимым endpoint ставить прокси или файрвол с жесткими лимитами на число заголовков. В отдельных инсталляциях частично помогают уже существующие кастомные ограничения, WAF, reverse proxy или сам факт, что backend не торчит наружу напрямую.
Для российских команд вывод предельно практичный. Если у вас HTTP/2 живет “по умолчанию” на edge-узлах, ingress-контроллерах, API-gateway или веб-серверах, это тот редкий случай, когда стоит не ждать очередного окна на техобслуживание, а проверить конфигурацию сразу. Нужен не общий аудит безопасности когда-нибудь потом, а очень конкретный чек: какие версии NGINX и Apache стоят в проде, где используются Envoy и IIS, есть ли лимиты на число заголовков, кто именно завершает HTTP/2-сессию и не полагаетесь ли вы на то, что малый объем входящего трафика автоматически означает малый риск. В 2026 году это уже слишком наивная гипотеза для протокола, который умеет эффективно работать и на благо пользователей, и против сервера.
HTTP/2 Bomb вряд ли станет последней атакой такого класса. Скорее наоборот: она хорошо показывает, как старые по отдельности идеи начинают работать по-новому, когда их соединяют в одном сценарии против реальных дефолтных конфигураций. Для разработчиков и SRE это неприятное, но полезное напоминание: опаснее всего не экзотика, а те места, где спецификация, удобные настройки и внутренняя экономика памяти вдруг сходятся не в пользу сервера. Технические детали, PoC и демонстрацию атаки можно проверить в публикации .