Apache HTTP/2: уязвимость CVE-2026-119618, версия 2.4.71

Что такое CVE-2026-119618?

CVE-2026-119618 - критическая уязвимость в mod_http2, модуле, который обрабатывает трафик HTTP/2 в Apache HTTP Server; она может привести к повреждению кучи и удалённому выполнению кода ^[1].

Apache описывает её как «уязвимость одновременного выполнения с использованием общего ресурса при неправильной синхронизации в mod_http2 сервера Apache HTTP Server, в assign_headers()», которая «может привести к RCE» ^[1]. CIRCL, национальная группа реагирования на компьютерные инциденты Люксембурга, поясняет, что при параллельной обработке потоков HTTP/2 рабочий процесс может изменить таблицу заголовков, выделенную для другого контекста выполнения, и такой небезопасный доступ к общей памяти способен повредить кучу ^[2].

Успешный атакующий мог бы выполнить код с правами процесса веб-сервера Apache, не входя в систему ^[2][4]. По оценке BleepingComputer, Apache HTTP Server работает примерно на каждом пятом сайте ^[4].

Исправление в основной ветке меняет одну запись в modules/http2/h2_request.c: вместо общей таблицы заголовков запроса используются собственные входные заголовки текущего запроса ^[2].

Какие версии Apache затронуты?

Затронуты Apache HTTP Server с 2.4.55 по 2.4.70, а также отдельные выпуски mod_h2 с 2.0.8 по 2.0.42 с GitHub; версия 2.4.71 это исправляет ^[1].

Пакеты дистрибутивов усложняют проверку версии. CIRCL советует организациям, использующим пакеты, которые поддерживают поставщики дистрибутивов, проверять бэкпорт исправления безопасности, а не полагаться только на номер версии основной ветки ^[2]. Red Hat, как резюмирует CIRCL, оценивает свои пакеты RHEL 9 и 10 как Important, а не Critical, поскольку их распределитель памяти затрудняет эксплуатацию, а RHEL 8 и более ранние версии называет незатронутыми ^[2].

Red Hat даёт общую оценку CVSS v3.1 9,8 (Critical) ^[2][3]. Собственная оценка Apache - Critical ^[1].

Уязвим ли мой сервер Apache?

Только если на нём работает затронутая сборка и он действительно принимает соединения HTTP/2: по словам Red Hat, серверы, настроенные только на HTTP/1.1, не уязвимы ^[3]. CIRCL подчёркивает, что код недостижим лишь потому, что mod_http2 установлен или загружен ^[2].

• Протоколом HTTP/2 управляет директива Protocols: «h2» включает его поверх TLS, а «h2c» - в открытом виде ^[2].
• В ядре Apache по умолчанию стоит http/1.1, и загрузка mod_http2 сама по себе этого не меняет ^[2]. BleepingComputer отмечает, что HTTP/2 по умолчанию отключён ^[4].
• Виртуальный хост может задать собственную директиву Protocols, поэтому проверка только глобальной конфигурации может пропустить сайт с включённым HTTP/2 ^[2].
• Если обратный прокси, балансировщик нагрузки или CDN завершает HTTP/2 и передаёт Apache только HTTP/1.1, сессия HTTP/2 клиента сама по себе не делает Apache достижимым, но протокол на каждом участке всё же стоит проверить ^[2].

CIRCL предлагает проверить версию и загруженные модули (apachectl -v, apachectl -M), настроенные виртуальные хосты (apachectl -S) и каждую явную настройку Protocols ^[2]. Тест, показывающий, что конечная точка принимает HTTP/2, не доказывает, что её бэкенд уязвим, а отрицательный тест не доказывает, что каждый порт или виртуальный хост отклоняет HTTP/2 ^[2].

Как проверить, принимает ли мой сервер HTTP/2?

CIRCL предлагает две проверки: просмотреть конфигурацию Apache на самом сервере, а затем проверить согласованный протокол из сети, желательно подключаясь прямо к Apache, а не через прокси ^[2].

1. Проверьте версию и модули. Выполните apachectl -v, чтобы увидеть версию, и apachectl -M с фильтром по http2, чтобы узнать, загружен ли модуль ^[2].
2. Перечислите виртуальные хосты. apachectl -S показывает все настроенные виртуальные хосты, а это важно, потому что у каждого может быть своя строка Protocols ^[2].
3. Найдите все директивы Protocols. CIRCL приводит команду grep, которая ищет явные настройки Protocols в /etc/apache2 и /etc/httpd, включая переопределения в виртуальных хостах; пути зависят от дистрибутива ^[2].
4. Проверьте TLS. Запрос curl с параметром --http2, выводящий версию HTTP, показывает, согласует ли конечная точка HTTPS протокол HTTP/2 ^[2].
5. Проверьте открытый вариант. curl с --http2-prior-knowledge проверяет, принимает ли обычная конечная точка HTTP протокол h2c ^[2].

Читайте результаты внимательно. Ответ с HTTP/2 показывает, что проверяемая конечная точка приняла HTTP/2, но не подтверждает, что её бэкенд Apache уязвим; отрицательный результат не доказывает, что каждый адрес, порт или виртуальный хост его отклоняет ^[2]. Совет CIRCL - вместе подтвердить действующую конфигурацию Apache и статус исправленного пакета у поставщика ^[2]. В облачных средах Wiz предупреждает, что скомпрометированный экземпляр Apache может стать точкой входа для бокового перемещения к соседним микросервисам или конечным точкам облачных метаданных - ещё одна причина проверять каждый экземпляр, а не только публичный сайт ^[5].

Как исправить CVE-2026-119618?

Обновитесь до Apache HTTP Server 2.4.71 или новее либо установите исправленный пакет вашего дистрибутива, затем перезапустите Apache и убедитесь, что работающие процессы используют новую сборку ^[2][1].

1. Обновите Apache. Установите 2.4.71 или сборку поставщика, явно исправленную от CVE-2026-119618 ^[2].
2. Обновите отдельный mod_h2, если вы им пользуетесь, по указаниям его поставщика; Wiz говорит переходить на версию выше 2.0.42, а CIRCL предупреждает не считать, что более новый отдельный выпуск существует, не проверив это ^[5][2].
3. Перезапустите и проверьте, что работающие процессы используют исправленную сборку ^[2].
4. Если обновиться пока нельзя, отключите HTTP/2: задайте Protocols http/1.1, уберите h2 и h2c из каждого переопределяющего виртуального хоста, проверьте через apachectl -t и перезагрузите конфигурацию ^[2]. Это перекрывает путь этой уязвимости, но не исправляет код ^[2].
5. Ограничьте доступ доверенными сетями как временную меру там, где нельзя ни обновиться, ни сменить протоколы ^[2].

Исследователи watchTowr подытожили это так: «обновляйтесь сейчас или отключите h2, пока не сможете», сообщает BleepingComputer ^[4]. SecurityWeek сообщает, что Defiant также предупредила: обновления безопасности WordPress не решают проблему, поскольку она затрагивает базовый веб-сервер ^[3].

Эксплуатируют ли CVE-2026-119618?

На момент публикации Wiz 11 ноября 2026 года эксплойта в открытом доступе не было и сообщений об эксплуатации в реальных атаках не поступало ^[5]. Однако ситуация быстро меняется.

• Red Hat говорит, что публичное исследование продемонстрировало надёжный эксплойт против сервера с включённым mod_http2, но в её бюллетене это исследование не названо ^[3]. CIRCL отмечает, что само по себе это не доказывает эксплуатацию в реальных атаках ^[2].
• Публичный PoC на GitHub сообщает о воспроизведении повреждения памяти и сбоев Apache, но не демонстрирует удалённое выполнение кода ^[3].
• Данные Wiz показывают, что в 64% облачных сред есть ресурсы с затронутыми версиями, а в 51% - публично доступные экземпляры; Wiz отмечает, что это не учитывает конфигурацию, так что такие системы не обязательно эксплуатируемы ^[5][3].

CIRCL перечисляет признаки, которые стоит изучить: неожиданные сбои рабочих процессов, аномальные перезапуски, подозрительные дочерние процессы, несанкционированные изменения файлов и неожиданные исходящие соединения ^[2]. Это зацепки, а не подтверждённые индикаторы компрометации, и обновление не удаляет закрепление, установленное до него ^[2].

Кто нашёл уязвимость Apache HTTP/2?

Apache указывает в авторстве OSS Scanner компании Anthropic, сообщивший об уязвимости 26 октября 2026 года, а также Энтони Уиемса и Саймона Сканнелла из Google Cloud Vulnerability Research, независимо сообщивших о ней 3 ноября ^[1].

Находка Anthropic указана под внутренним идентификатором ANT-2026-MAPKT6MZ ^[1]. SecurityWeek описывает два сообщения как независимые открытия ^[3]. Это ещё один пример того, как автоматизированные и ИИ-инструменты находят серьёзные ошибки в широко используемом открытом ПО; что означает эта тенденция, разбирает материал AI That Finds Security Bugs: What Glasswing and New CVEs Mean for You.

Исправление было внесено, а 2.4.71 выпущена 11 ноября, в тот же день, когда Apache раскрыла проблему в рассылке oss-security ^[1][2].

Что ещё исправляет Apache 2.4.71?

Apache HTTP Server 2.4.71 исправляет в сумме три CVE: одну критическую, одну важную и одну низкой степени ^[1].

• CVE-2026-106023 (важная): разыменование нулевого указателя в mod_md при обработке запроса, способное привести к сбою дочернего процесса; затрагивает версии с 2.4.30 по 2.4.70 ^[1].
• CVE-2026-109163 (низкая): перезапись одного байта буфера стека в mod_vhost_alias, которую Apache помечает как «после CVE-2026-63292» (эта более ранняя уязвимость была исправлена в 2.4.69); затрагивает 2.4.69 и 2.4.70 ^[1].

Предыдущий выпуск, 2.4.69 в октябре 2026 года, исправил 20 CVE ^[1]. Администраторы, которые его пропустили, получат и эти исправления, перейдя на 2.4.71. О другой недавней уязвимости серверов читайте в материале CVE-2026-98432 Explained: The Linux TCP Flaw and How to Protect Your Servers.

За чем следить администраторам дальше?

Следите за появлением публичного эксплойта удалённого выполнения кода, бэкпортами поставщиков для вашего дистрибутива и сообщениями об атаках в реальных условиях ^[3][5].

CIRCL рекомендует составить перечень экземпляров с включённым HTTP/2, проверить, затронута ли каждая сборка mod_http2, и без промедления обновлять доступные системы, в первую очередь сайты и API в интернете, виртуальный хостинг и серверы Apache за фронтендами, которые передают HTTP/2 ^[2]. Организациям, заметившим подозрительную активность, следует действовать по процедурам реагирования на инциденты и обратиться в национальную группу CSIRT ^[2].