Критическая уязвимость CVE-2026-49975 в nginx и Apache позволяла удаленно уронить сервер за секунды, причем без логина, токенов и каких-либо экзотических настроек. Для русскоязычной IT-аудитории это не абстрактная история про «очередной CVE», а вполне прикладной риск: если у вас включены TLS и HTTP/2, а веб-сервер работает в дефолтной конфигурации, атака могла упереться не в сложность эксплуатации, а только в то, успеете ли вы поставить обновление.
Об устранении проблемы в SELECTOS, как пишет Habr / Новости, сообщили в блоге Selectel. Речь идет о DoS-уязвимости CVE-2026-49975, затрагивающей веб-серверы nginx и Apache. По описанию, она позволяла злоумышленнику удаленно исчерпать всю доступную память сервера буквально за секунды. Важная деталь: аутентификация не требовалась, а эксплуатация была возможна в конфигурации «по умолчанию» при включенных TLS и HTTP/2. Для администраторов и платформенных команд это как раз тот класс проблем, который опасен не тонкостью, а банальной доступностью.
Сама атака получила название HTTP/2 Bomb. В ее основе сочетание двух механизмов. Первый — так называемая HPACK-бомба, которая дает усиление по памяти до 5700:1. Второй — блокировка управления потоком. В итоге даже однобайтовый запрос может заставить сервер выделить гигабайты памяти и при этом не освободить их вовремя. С инженерной точки зрения это особенно неприятный сценарий: нагрузка на атакующего минимальна, а цена ошибки на стороне сервера максимальна. Если говорить совсем приземленно, то речь не про долгую осаду инфраструктуры, а про возможность быстро положить сервис, фронт, внутреннюю панель или API-шлюз.
Проблема не ограничивается двумя самыми заметными именами в списке. Помимо nginx и Apache, уязвимость затрагивает Microsoft IIS, Envoy и Pingora. Это расширяет радиус риска далеко за пределы классических Linux-стеков с привычной связкой «nginx перед приложением». Для компаний, у которых в инфраструктуре смешанный парк прокси, балансировщиков и edge-компонентов, история выглядит уже не как точечный патч, а как инвентаризация всей HTTP/2-поверхности. И здесь обычно всплывает знакомая реальность: в документации у всех красиво, а в проде часть сервисов давно живет по принципу «не трогай, пока отвечает».
В SELECTOS исправления доступны, начиная с конкретных версий пакетов: apache2 — 2.4.67-1~deb12u2+sel1u1, nginx — 1.22.1-9+deb12u7+sel1u1. Это полезно тем, что администратору не нужно гадать, «входит ли фикс в последнее обновление», а можно сразу сверить пакетную версию. Для установки актуальных сборок предлагается либо полное обновление системы через apt update и apt upgrade, либо точечное обновление конкретного веб-сервера: отдельно nginx или отдельно apache2. На практике второй путь часто выбирают там, где любое общее обновление сервера требует отдельного окна изменений, согласований и неизбежного вопроса «а что еще приедет вместе с патчем».
Важно и то, что уязвимость проявляется при включенных TLS и HTTP/2 — то есть не в какой-то редкой лабораторной сборке, а в довольно обычной для современного веба конфигурации. HTTP/2 давно стал стандартной опцией ради производительности, мультиплексирования и более аккуратной работы с соединениями. TLS тоже никто добровольно не выключает, если только не хочется объясняться с безопасниками, клиентами и браузером пользователя одновременно. Поэтому CVE-2026-49975 цепляет именно те настройки, которые включают потому, что «так и должно быть». И в этом главная неприятность: уязвимость живет не на периферии стека, а в его нормальном рабочем режиме.
Для разработчиков эта новость — напоминание, что отказоустойчивость приложения не спасает, если первым падает веб-сервер или прокси-слой. Можно долго профилировать код, строить лимиты по rate limiting, оптимизировать базу и очереди, но если инфраструктурный компонент выделяет гигабайты памяти в ответ на крошечный пакет, то приложение просто не получает шанса показать свою устойчивость. Для DevOps- и SRE-команд вывод еще прямее: проверка версий nginx и Apache после такой публикации — не факультативная гигиена, а базовая реакция на инцидентный класс риска. Особенно если у сервиса высокие требования к доступности или он смотрит в интернет без дополнительного защитного контура перед фронтом.
Для бизнеса смысл тоже прозрачен, хотя он обычно формулируется без аббревиатур. DoS на уровне веб-сервера — это простой сайта, панели клиента, кабинета партнера или внутреннего портала. Даже если атака не ведет к краже данных, она быстро превращается в SLA-проблему, потерю заявок и нагрузку на поддержку. А если инфраструктура типовая и масштабная, окно между публикацией детали проблемы и массовой проверкой внешними сканерами может оказаться очень коротким. В таких историях проигрывает не тот, у кого «плохой стек», а тот, у кого процессы обновления слишком медленные для уязвимостей, работающих из коробки.
История с CVE-2026-49975 хорошо показывает сдвиг, который рынок наблюдает уже не первый год: даже зрелые и повсеместно используемые сетевые компоненты остаются точкой быстрого отказа, если в протоколе или его реализации находится удачная комбинация усиления и удержания ресурсов. Чем активнее компании включают современные транспортные возможности вроде HTTP/2 по умолчанию, тем выше цена не самого факта уязвимости, а задержки между ее появлением и установкой патча. И вопрос здесь уже не в том, найдется ли следующий изящный способ превратить байты запроса в гигабайты аллокаций, а в том, у скольких команд обновление веб-сервера все еще устроено как бюрократический квест вместо штатной процедуры.