Apache исправил критическую уязвимость HTTP/2: что проверить владельцу сайта

11 ноября 2026 года проект Apache HTTP Server выпустил версию 2.4.71 с исправлением критической уязвимости CVE-2026-119618 в модуле HTTP/2. Если ваш сайт или интернет-магазин обслуживает Apache, попросите администратора проверить используемый модуль и наличие исправления. На виртуальном хостинге этот вопрос нужно адресовать провайдеру; на VPS и выделенном сервере — ответственному за обслуживание.

Apache классифицирует проблему как critical: ошибка синхронизации при параллельной обработке в mod_http2 может привести к повреждению памяти и удалённому выполнению кода. В бюллетене указаны версии Apache HTTP Server от 2.4.55 до 2.4.70 включительно. Исправление вошло в 2.4.71.

Для отдельно распространяемого через GitHub mod_h2 указан собственный диапазон затронутых выпусков: 2.0.8–2.0.42. Если модуль устанавливался отдельно, его происхождение и исправление нужно проверить отдельно от основного пакета веб-сервера.

Red Hat уточняет: уязвимость затрагивает серверы с включённым HTTP/2. Поставщик сообщает о демонстрации работоспособного эксплойта в публичном исследовании; это не равнозначно подтверждённым атакам на реальные сайты. Оснований объявлять все затронутые сайты взломанными нет. Географических ограничений в бюллетене Apache не указано.

Оценка зависит от пакета. Red Hat относит свои mod_http2 для RHEL 9 и 10 к уровню Important, поскольку особенности выделения памяти усложняют эксплуатацию, и указывает, что RHEL 8 и более ранние выпуски не затронуты. Это заявление относится к пакетам Red Hat: его нельзя автоматически переносить на стороннюю сборку или отдельно установленный модуль.

• Установите, участвует ли Apache в обработке запросов каждого сайта и используется ли mod_http2. CDN или другой сервер перед Apache сами по себе не подтверждают защищённость внутреннего компонента.
• Уточните источник пакета и полный номер сборки. Дистрибутив Linux или поставщик поддержки может перенести исправление в пакет с прежним базовым номером версии; запросите его бюллетень и подтверждение закрытия CVE.
• Согласуйте установку поддерживаемого исправления и необходимые перезапуски. Важно, чтобы обновление использовали работающие процессы, а не только файлы пакета на диске.
• После работ проверьте вход, формы, загрузку файлов, корзину, оформление заказа и используемые интеграции. Выберите проверки по функциям своего проекта.

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

Попросите короткое подтверждение: какие экземпляры Apache проверены, каким пакетом устранена CVE-2026-119618, применено ли исправление работающими процессами и проверены ли основные операции сайта. Если появились признаки вмешательства, сохраните журналы до очистки и привлеките специалиста по расследованию. Патч не устраняет автоматически последствия возможной прежней компрометации.

Сведения проверены 12 ноября 2026 года, 17:58 МСК. Исправление Apache HTTP Server 2.4.71 выпущено 11 ноября; точное время выпуска в объявлении не указано.

On November 11, 2026, the Apache HTTP Server project released version 2.4.71 with a fix for the critical CVE-2026-119618 vulnerability in the HTTP/2 module. If your website or online store is served by Apache, ask your administrator to check the module in use and confirm the patch is applied. For shared hosting, address this issue with your provider; for VPS and dedicated servers, contact the responsible maintenance team.

Apache classifies the issue as critical: a synchronization error during parallel processing in mod_http2 can lead to memory corruption and remote code execution. The bulletin lists Apache HTTP Server versions from 2.4.55 to 2.4.70 inclusive. The fix was included in version 2.4.71.

For the separately distributed mod_h2 via GitHub, a separate range of affected releases is specified: 2.0.8–2.0.42. If the module was installed separately, its origin and the patch status must be verified independently from the main web server package.

Red Hat clarifies: the vulnerability affects servers with HTTP/2 enabled. The vendor reports a demonstration of a working exploit in a public study; this is not equivalent to confirmed attacks on live sites. There is no basis for declaring all affected sites compromised. The Apache bulletin does not specify geographic restrictions.

The assessment depends on the package. Red Hat rates its mod_http2 for RHEL 9 and 10 as Important because memory allocation specifics complicate exploitation, and notes that RHEL 8 and earlier releases are unaffected. This statement applies to Red Hat packages: it cannot be automatically transferred to a third-party build or a separately installed module.

• Verify whether Apache handles requests for each site and whether mod_http2 is in use. A CDN or another server in front of Apache does not by itself confirm the security of the internal component.
• Specify the package source and the full build number. A Linux distribution or support provider may backport a fix into a package with an older base version number; request its bulletin and confirmation of the CVE closure.
• Coordinate the installation of the supported fix and any required restarts. It is critical that running processes use the update, not just the package files on disk.
• After the work, check login, forms, file uploads, the shopping cart, checkout, and the integrations used. Select checks based on the features of your project.

Before changing the configuration, save a backup and prepare a recovery plan. Do not manually replace packages or disable protocols with a single command without evaluating dependencies. If the update is not yet available, request temporary measures from the provider specifically for this vulnerability and your configuration.

Request a brief confirmation: which Apache instances have been checked, which package fixed CVE-2026-119618, whether the patch has been applied to running processes, and whether core site operations have been verified. If signs of interference appear, save logs before cleanup and engage a forensic specialist. The patch does not automatically resolve the consequences of a possible prior compromise.

Information verified on November 12, 2026, at 17:58 MSK. The Apache HTTP Server 2.4.71 fix was released on November 11; the exact release time is not specified in the announcement.