Исследователи Calif раскрыли атаку HTTP/2 Bomb, получившую идентификатор CVE-2026-49975. Она позволяет удалённо перегружать память веб-серверов с включённым HTTP/2 и может затронуть NGINX, Apache HTTP Server, Microsoft IIS, Envoy и Cloudflare Pingora.
Уязвимость затрагивает серверы с HTTP/2 в стандартной конфигурации
В начале июня 2026 года исследовательская группа Calif опубликовала разбор HTTP/2 Bomb — удалённой атаки отказа в обслуживании на реализации HTTP/2. По данным авторов исследования, риск связан с поведением популярных серверов в стандартной конфигурации HTTP/2: NGINX, Apache httpd, Microsoft IIS, Envoy и Cloudflare Pingora.
Проблема получила идентификатор CVE-2026-49975. HKCERT 4 июня 2026 года выпустил бюллетень с высоким уровнем риска и отметил, что для уязвимости уже доступен публичный proof-of-concept. Это повышает практическую опасность: администраторам приходится реагировать быстрее, потому что экспериментальный код атаки уже может быть адаптирован злоумышленниками.
Для обычного владельца сайта суть проста: сервер может перестать отвечать на запросы из-за нехватки памяти. Данные пользователей при такой атаке напрямую не похищаются, но сайт, API, личный кабинет или платёжная форма могут стать недоступными.
Атака объединяет сжатие заголовков и удержание соединения
HTTP/2 ускоряет загрузку сайтов за счёт более эффективной передачи данных. Один из механизмов — HPACK, сжатие HTTP-заголовков. Оно помогает не пересылать одни и те же заголовки полностью при каждом запросе: клиент и сервер используют таблицу повторяющихся значений.
HTTP/2 Bomb использует этот механизм в связке с техникой медленного удержания соединения. Исследователи описывают цепочку из двух идей:
- клиент отправляет компактные закодированные заголовки, которые на стороне сервера превращаются в заметные внутренние структуры данных;
- затем соединение удерживается так, чтобы сервер продолжал хранить выделенную память и не освобождал её вовремя.
В результате небольшой поток входящих данных может создать непропорционально большую нагрузку на память. По оценке Calif и пересказу профильных изданий, в отдельных сценариях один клиент с каналом около 100 Мбит/с способен быстро занять десятки гигабайт оперативной памяти на уязвимом сервере.
Публичный PoC ускоряет переход от исследования к реальным инцидентам
Ключевой риск HTTP/2 Bomb связан не только с самой техникой, но и с доступностью деталей. Calif опубликовала техническое описание и лабораторные материалы, а HKCERT отдельно указал на наличие публичного proof-of-concept для CVE-2026-49975.
Для защитников это полезно: команды безопасности могут воспроизвести проблему в тестовой среде и проверить эффективность обновлений. Для атакующих это тоже снижает порог входа. Поэтому ситуация особенно важна для публичных сайтов, API-шлюзов, reverse proxy, ingress-контроллеров Kubernetes и сервисов, где HTTP/2 включён автоматически.
Отдельное внимание привлекло участие OpenAI Codex в исследовании. По словам Calif, агент помог связать ранее известные идеи в рабочую цепочку атаки. Это важный сигнал для индустрии: старые классы ошибок в протоколах и библиотеках могут быстрее превращаться в практические эксплойты при помощи современных инструментов анализа кода.
NGINX и Apache получили конкретные пути исправления
Для NGINX исследователи указывают обновление до версии 1.29.8 и новее. В этой версии появился параметр max_headers с ограничением по умолчанию, который снижает риск злоупотребления большим числом заголовков. Если обновление невозможно, временной мерой остаётся отключение HTTP/2 на уязвимом сервере.
Для Apache httpd исправление связано с mod_http2 v2.0.41. В описании Calif говорится, что патч меняет обработку cookie-заголовков так, чтобы они учитывались в лимитах LimitRequestFields. Это важно, потому что особая обработка cookie в HTTP/2 могла усиливать эффект атаки.
По данным Radware от 4 июня 2026 года, NGINX и Apache уже имеют исправления, а статус Microsoft IIS, Envoy и Cloudflare Pingora на момент публикации требовал отдельной проверки у поставщиков. Calif также сообщала об обновлении по Envoy от 3 июня и продолжала проверку результата. Поэтому администраторам нужно смотреть именно актуальные advisory своих вендоров и дистрибутивов.
Владельцам сайтов стоит проверить HTTP/2 на внешнем периметре
Главный практический шаг — инвентаризация. Нужно понять, где именно включён HTTP/2: на NGINX, Apache, CDN, балансировщике, ingress-контроллере, API-gateway или Windows-сервере с IIS. Часто HTTP/2 включается на внешнем TLS-терминаторе, а приложение за ним может даже не знать о протоколе клиента.
Минимальный план действий для администратора:
- обновить NGINX до 1.29.8+ или применить исправления из пакетов своего дистрибутива;
- обновить Apache/mod_http2 до версии с исправлением CVE-2026-49975;
- проверить advisory для IIS, Envoy, Pingora, CDN и облачного балансировщика;
- временно отключить HTTP/2 там, где патча пока нет и риск простоя критичен;
- настроить жёсткие лимиты на количество заголовков, память воркеров и длительность соединений;
- вынести публичные сервисы за WAF, reverse proxy или Layer 7 load balancer с проверенными ограничениями.
Отключение HTTP/2 может немного повлиять на производительность некоторых сайтов, особенно при большом количестве параллельных запросов. Для большинства проектов кратковременное снижение эффективности будет менее болезненным, чем риск отказа сервиса из-за переполнения памяти.
Риск выше для публичных API и серверов без защитного слоя
HTTP/2 Bomb особенно опасна для сервисов, которые принимают прямые подключения из интернета. Это могут быть публичные API, SaaS-панели, корпоративные порталы, Kubernetes ingress, прокси перед микросервисами и сайты с высокой долей динамического трафика.
Если перед сервером стоит CDN или защищённый балансировщик, риск зависит от того, где завершается HTTP/2-соединение и какие ограничения применяет этот слой. Если CDN принимает HTTP/2 от пользователя, а к origin-серверу ходит по HTTP/1.1, атака может быть остановлена раньше. Если HTTP/2 пробрасывается глубже в инфраструктуру, проверку нужно проводить на каждом уровне.
Важный нюанс: обычный мониторинг CPU может не показать проблему заранее. Такая атака бьёт по памяти и количеству удерживаемых соединений. Поэтому полезно отдельно отслеживать рост RSS-памяти процессов, OOM-события, число активных HTTP/2-streams, ошибки 502/503/504 и резкий рост долгоживущих соединений.
Обновление серверов снижает риск массовых отказов
HTTP/2 Bomb показывает, что даже зрелые сетевые протоколы требуют регулярной проверки реализаций и разумных лимитов по умолчанию. Для владельцев сайтов главный вывод практический: нужно быстро проверить наличие HTTP/2 на внешнем периметре, применить обновления и временно отключить протокол там, где патча пока нет.
Следующий шаг для администраторов — сверить версии NGINX, Apache, IIS, Envoy, Pingora и используемых дистрибутивных пакетов с актуальными рекомендациями поставщиков. Для проектов с критичной доступностью стоит провести тестовую проверку в staging-среде и заранее подготовить конфигурацию аварийного отключения HTTP/2.
