Apache HTTP Server: критическая RCE в mod_http2, исправление в 2.4.71

Apache Software Foundation выпустила HTTP Server 2.4.71 с исправлением критической уязвимости CVE-2026-119618. Ошибка в модуле mod_http2 позволяет удалённому атакующему без учётной записи вызвать повреждение кучи и выполнить код с правами веб-сервера. Уязвимы версии с 2.4.55 по 2.4.70, а также сборки mod_h2 с 2.0.8 по 2.0.42. На момент публикации анализа публичного эксплойта не было, данных об эксплуатации в реальных атаках тоже.

Что известно об ошибке в mod_http2

Суть ошибки

Проблема находится в функции assign_headers(), которая раскладывает заголовки ответа. Несколько потоков обращаются к общим структурам без должной синхронизации: одновременная обработка запросов создаёт состояние гонки, CWE-362. Атакующий подбирает запросы так, чтобы испортить память кучи, и из повреждения получает выполнение кода.

Для эксплуатации не нужны учётная запись и действия пользователя. Нужен только включённый HTTP/2: ошибка живёт в модуле mod_http2, и на серверах, где протокол не используется, уязвимый код не участвует в обработке запросов.

Состояние гонки зависит от совпадения потоков, поэтому надёжность эксплуатации может меняться от конфигурации к конфигурации. Это не снижает приоритет: при большом числе одновременных запросов окно для атаки открывается чаще.

HTTP/2 мультиплексирует запросы в одном соединении, поэтому один клиент легко создаёт конкуренцию потоков. Чем больше одновременных запросов, тем выше шанс попасть в окно гонки.

Затронутые версии

Уязвимы Apache HTTP Server с 2.4.55 по 2.4.70 включительно. Отдельная ветка риска - сборки mod_h2 с GitHub с 2.0.8 по 2.0.42: их нужно обновить выше 2.0.42, даже если сам сервер обновлён отдельно. Исправление вышло в Apache HTTP Server 2.4.71. Проверять нужно и сам сервер, и модуль: в дистрибутивах они могут обновляться разными пакетами.

В 2.4.71 вошли ещё две уязвимости: ошибка mod_md с разыменованием нулевого указателя и падением дочернего процесса, а также переполнение буфера в mod_vhost_alias. Всего в релизе три CVE: одна критическая, одна важная и одна низкая. Обновление до 2.4.71 закрывает их одновременно.

Как нашли

Ошибку независимо обнаружили две команды. Anthropic нашла её сканером OSS Scanner, в бюллетене Apache указан идентификатор ANT-2026-MAPKT6MZ. Anthony Weems и Simon Scannell из Google Cloud Vulnerability Research пришли к тому же результату независимо.

В Apache уязвимость зарегистрировали 26 октября и 3 ноября 2026 года. Исправление выпустили 11 ноября вместе с релизом 2.4.71. Публичный характер исправления означает, что разобрать изменение в коде и попытаться повторить атаку может любой желающий.

Насколько это опасно

Apache оценил ошибку как критическую, хотя числовую оценку CVSS в записи CVE не приводит. Уязвимость даёт выполнение команд с правами процесса веб-сервера, а этот процесс обычно читает конфигурацию, файлы сайтов и секреты приложений. На публичном хостинге за одним сервером стоят десятки сайтов, поэтому компрометация затрагивает не одну площадку.

Аналитики Wiz отмечают, что в облаке взломанный экземпляр Apache становится точкой входа для бокового перемещения. Из контейнера или виртуальной машины он может достучаться до соседних микросервисов и метаданных облачных инстансов. Для распределённых развёртываний это расширяет последствия за пределы одного сайта.

Публичного эксплойта на момент публикации анализа не было, и данных об эксплуатации в реальных атаках нет. Для критической RCE с публичным патчем это спокойствие обычно недолгое: у атакующих появляется точная карта уязвимого кода.

Что даёт эксплуатация

С правами веб-сервера атакующий читает конфигурацию виртуальных хостов, ключи TLS, параметры подключения к базам данных и переменные окружения приложений. Часто этого достаточно, чтобы получить доступ к админпанелям и внутренним сервисам, которые доверяют серверу.

На сервере с несколькими сайтами одно выполнение кода затрагивает все площадки сразу: общие файлы, общие сертификаты и общий процесс. Даже если конкретный сайт обновлён, соседний виртуальный хост на том же Apache остаётся путём внутрь. Код можно закрепить в общем каталоге модулей, и тогда перезапуск сервиса его не удалит.

Что делать

Обновите Apache HTTP Server до 2.4.71 или более новой версии. Отдельно проверьте сборки mod_h2 из GitHub: они должны быть новее 2.0.42. Если сервер собран из исходников, пересоберите его целиком, а не только модуль: версия модуля и версия ядра сервера должны быть согласованы.

Для пакетов из репозитория дистрибутива дождитесь обновления от мейнтейнера. Если обновление откладывается, временно отключите HTTP/2 и оставьте только HTTP/1.1. Такой вариант убирает уязвимый код из обработки запросов, но снижает производительность и не устраняет ошибку в модуле. Держать его как постоянную меру не стоит.

В первую очередь обновляйте серверы, которые смотрят в интернет и принимают HTTP/2. Дальше - внутренние площадки, контейнерные образы и сборки, которые используются повторно: старая версия в базовом образе тиражируется на все развёртывания.

Как проверить, что риск закрыт

Сверьте версию сервера в консоли и проверьте, включён ли h2 или h2c в конфигурации. На терминаторах TLS, балансировщиках и в контейнерных образах версия может отличаться от той, что установлена на хосте.

Отдельно проверьте обратные прокси и балансировщики, которые терминируют HTTP/2: там тоже может стоять уязвимый Apache. После обновления перезапустите сервис и убедитесь, что старые модули не остались в загружаемых путях. Для контейнеров пересоберите образ, а не только обновите пакет в запущенном контейнере.