CVE-2026-119618: Критична уразливість Apache HTTP/2 дозволяє виконання віддаленого коду

Apache випустила термінове оновлення безпеки для усунення CVE-2026-119618, критичної вразливості віддаленого виконання коду в модулі mod_http2 сервера Apache HTTP Server. Помилка впливає на версії Apache HTTP Server від 2.4.55 до 2.4.70, і може дозволити неавтентифікованому віддаленому зловмиснику пошкодити пам’ять купи і потенційно виконати довільні команди на вразливих серверах.

Вразливість виникає через неналежну синхронізацію, коли Apache обробляє паралельні HTTP/2 запити. Багато потоків можуть отримувати доступ до спільних ресурсів без достатньої координації, створюючи стан гонитви, що дозволяє одному потоку змінювати пам’ять, яка використовує інший. Успішна експлуатація може пошкодити внутрішню купу сервера і, в кінцевому рахунку, призвести до віддаленого виконання коду.

Лише розгортання Apache з увімкненим HTTP/2 піддаються відомому шляху атаки. Сервери, налаштовані виключно для HTTP/1.1, не досягають уразливої функціональності mod_http2. HTTP/2 може бути ввімкнено з використанням h2 для TLS-з’єднань або h2c для незашифрованого HTTP/2 через директиву Protocols в Apache.

Зв’язок з відділом продажів

Apache усунула вразливість в HTTP Server 2.4.71, випущеній 11 листопада 2026 року. Окремі випуски mod_h2 з GitHub версій від 2.0.8 до 2.0.42 також піддаються впливу. Офіційна рекомендація Apache наразі не визначає окремо випущеної виправленої версії standalone mod_h2.

Red Hat оцінив вразливість з CVSS 3.1 на рівні 9.8 для загальної оцінки, з можливістю мережевого доступу та експлуатації низької складності, яка не вимагає автентифікації або взаємодії з користувачем. Red Hat також зазначає, що дослідження продемонструвало надійну експлуатацію проти сервера, налаштованого за замовчуванням, з увімкненим mod_http2.

Однак станом на 12 листопада 2026 року, ні Apache, ні переглянуті звіти безпеки не документують експлуатації у реальних атаках. Wiz також не повідомила про відому експлуатацію на момент публікації. Організації все ж повинні пріоритизувати усунення, оскільки вразливість може бути досягнута віддалено, і її технічна причина вже стала публічною.

Організації можуть зміцнити захист від нових експлуатацій за допомогою платформи SOC Prime AI-Native Detection Intelligence, дозволяючи командам безпеки вводити в дію розвідувальні дані про загрози та прискорити розробку виявлення та полювання на загрози у середовищах SIEM, EDR, XDR і Data Lake.

Виявити CVE-2026-119618 можна, ідентифікувавши уразливі сервери Apache з ввімкненим HTTP/2, які подаються в інтернет, і корелюючи підозрілу HTTP/2 активність з аваріями Apache, аномальними дочірніми процесами, несподіваним виконанням команд, новоствореними файлами й незвичайними вихідними мережевими з’єднаннями.

Зміст виявлення може бути недоступним для кожного CVE. Перевірте платформу SOC Prime на наявність поточного покриття. Якщо відповідні виявлення ще не доступні, перевірте знову, оскільки нові розвідувальні дані про загрози і контент виявлення додаються постійно.

Аналіз CVE-2026-119618

CVE-2026-119618 впливає на Apache HTTP Server версій 2.4.55 до 2.4.70, коли присутня уразлива функціональність mod_http2 і HTTP/2 ввімкнено. Проект standalone mod_h2 піддається впливу з версії 2.0.8 до 2.0.42. Apache класифікує проблему як критичну і відносить її до CWE-362, Паралельне виконання з використанням спільного ресурсу без належної синхронізації.

Вразливість існує у функції assign_headers(), що використовується обробкою HTTP/2 Apache.

HTTP/2 значно відрізняється від HTTP/1.1, оскільки кілька потоків можуть функціонувати одночасно через одне з’єднання. Модуль mod_http2 Apache, отже, використовує кілька потоків для обробки запитів і управління потоками HTTP/2 одночасно.

Проблема виникає, коли ці потоки взаємодіють з спільною пам’яттю без належної синхронізації. Відповідно до технічної оцінки Red Hat, робітник stream HTTP/2 може записувати у пам’ять, яка знаходиться у володінні потоку з’єднання, через спільний, безблоковий розподілювач.

При доступі, контрольованому атакуючим, паралельний доступ може пошкодити купу.

Вразливості пошкодження купи можуть мати різні наслідки залежно від розташування пам’яті і контролю з боку зловмисника. Невдала експлуатація може призвести до аварії процесів робітників Apache, тоді як достатньо контрольоване порушення може змінити стан програми або перенаправити виконання.

Red Hat стверджує, що успішна експлуатація може дозволити неавтентифікованому зловмиснику виконувати довільні команди з привілеями процесу сервера Apache HTTP. Це може дати зловмисникам доступ до даних додатків, конфігураційних файлів, облікових даних, доступних веб-серверу, та іншим ресурсам, доступним під цим контекстом безпеки.

Ця вразливість є особливо небезпечною для систем, доступних з інтернету, оскільки для неї не потрібна дійсна обліковка, пароль, ключ API або інша аутентифікація. Атакуючий потребує лише мережевий доступ до вразливого кінцевого пункту HTTP/2.

Тим не менш, експозиція залежить від конфігурації.

Сервер Apache HTTP фактично повинен пропонувати HTTP/2. Адміністратори можуть увімкнути його через директиву Protocols з використанням:

Protocols h2 http/1.1

для HTTP/2 з TLS, або:

Protocols h2c http/1.1

де підтримується незашифрований HTTP/2.

Директива може бути налаштована глобально або для індивідуальних віртуальних хостів, що означає, що адміністратори повинні перевіряти як серверні, так і на сайті конфігурації при оцінці експозиції.

Сервер, який запускає вразливу версію Apache, але обслуговує тільки HTTP/1.1, не вразливий через цю помилку. Red Hat конкретно підтверджує, що системи без увімкненого HTTP/2 не досягають уразливого шляху коду.

Межі впливу Apache, визначені верхнім рівнем, також не повинні застосовуватися неоправдано до пакетів дистрибуцій Linux.

Red Hat Enterprise Linux 8 та раніші версії не містять уразливий код і не піддаються впливу. RHEL 9 і RHEL 10 включають вразливі пакети mod_http2, але Red Hat оцінює цю проблему як Важливу, а не як Критичну на цих платформах.

Різниця полягає в деталях реалізації. У RHEL 9 і 10 кожен потік HTTP/2 отримує окремий розподілювач пам’яті, а не ділить той же розподілювач з з’єднанням. Red Hat стверджує, що така архітектура суттєво ускладнює експлуатацію, хоча уразливі системи все ще потребують оновлень безпеки.

Red Hat випустила виправлені пакети для багатьох потоків RHEL 9 і RHEL 10 11 листопада. Адміністратори, які використовують пакети Linux, що підтримуються постачальником, повинні застосувати оновлення безпеки їхньої дистрибуції замість визначати вразливість лише за версією Apache, що відображається сервером.

Apache HTTP Server 2.4.71 забезпечує верхньорівневе виправлення. Виправлення модифікує уразливу поведінку синхронізації і управління пам’яттю, так щоб паралельні операції HTTP/2 не могли взаємодіяти з ураженими спільними ресурсами у ненадійному способі.

Вразливість була незалежно виявлена під час двох науково-дослідних робіт.

Сканер OSS компанії Anthropic повідомив про проблему команді безпеки Apache 26 жовтня 2026 року під ідентифікатором ANT-2026-MAPKT6MZ. Ентоні Вімс і Саймон Сканнелл з дослідницької групи Google Cloud Vulnerability незалежно повідомили про вразливість 3 листопада. Apache випустила виправлення 11 листопада.

Запис CVE був опублікований 11 листопада 2026 року.

Ситуація з CVE-2026-119618 PoC вимагає обережної інтерпретації. Red Hat зазначає, що публічні дослідження продемонстрували надійний експлойт проти сервера з налаштованими за замовчуванням параметрами, з увімкненим mod_http2. Проте, The Hacker News і Wiz повідомили, що жоден їхній публічно доступний експлойт RCE не було ідентифіковано за часом публікації звітів. Публічні проекти на GitHub, які заявляють про сканери або інструменти, пов’язані з експлуатацією, не повинні автоматично тлумачитися як достовірно уніфікований код RCE.

Це розрізнення має значення з точки зору операцій. Захисники повинні припускати, що вразливість є технічно експлуатованою, уникаючи заяв, що надійний уніфікований експлойт вже поширено широко, доки не з’являться додаткові докази.

Для виявлення CVE-2026-119618 команди безпеки повинні спочатку виявити системи, піддані впливу, а не покладатися лише на підписи експлойтів.

Адміністратори можуть підтвердити, чи завантажено модуль HTTP/2, скориставшись:

apachectl -M | grep http2

Потім вони повинні перевірити файли конфігурації Apache на наявність директив Protocols, що містять h2 або h2c, включаючи директиви, визначені всередині індивідуальних віртуальних хостів.

Зовнішнє виявлення сервісів може також ідентифікувати сервери, що домовляються про HTTP/2 через TLS ALPN. Тим не менш, одна лише ідентифікація версії може вводити в оману, оскільки дистрибуції Linux часто виконують виправлення вразливостей без зміни рядка версії, що виглядає як верхньорівневий.

Телеметрія виконання повинна бути корельована з підозрілим трафіком HTTP/2. Можливі поведінкові індикатори включають повторювані аварії робітників Apache, порушення сегментації, аномальні перезапуски, повідомлення про пошкодження пам’яті або раптову нестабільність сервісу, що асоціюється з незвичайними вибухами запитів HTTP/2.

Оскільки успішна експлуатація може забезпечити виконання команд, телеметрія кінцевих точок і хостів також повинна бути переглянута на предмет незвичайних дочірніх процесів, що походять від Apache.

Приклади включають httpd або apache2, що несподівано запускають shell’и, інтерпретатори скриптів, утиліти для завантаження або системні адміністративні команди.

Команди безпеки повинні розслідувати взаємозв’язки процесів, такі як:

httpd → /bin/sh

apache2 → bash

httpd → curl

apache2 → wget

або інші ланцюжки виконання, які не відповідають нормальній поведінці хостованого додатка.

Створення файлів у тимчасових каталогах, веб-коренях, місцях запуску або записуваних папках додатків також може вказувати на діяльність після експлуатації. Несподівані вихідні з’єднання з процесів робітників Apache повинні отримати таку ж увагу.

В даний час немає опублікованих постачальниками специфічних для кампанії IOCs CVE-2026-119618, таких як зловмисні IP-адреси, домени, геші кордонів або інфраструктура атакуючих, оскільки Apache та переглянуті джерела не повідомили про експлуатацію на волі. Це робить оцінку конфігурації та моніторинг на основі поведінки більш цінними, ніж статичне зіставлення індикаторів.

Зменшення впливу CVE-2026-119618

Основним заходом для усунення є оновлення вразливих установок Apache HTTP Server до версії 2.4.71 або застосування виправленого пакету безпеки, наданого постачальником операційної системи. Apache 2.4.71 була випущена 11 листопада 2026 року і містить верхньорівневе виправлення.

Організації повинні пріоритизувати розгортання Apache з HTTP/2, що піддаються інтернет-експозиції, оскільки ці системи піддають уразливу функціональність безпосередньо ненадійними мережевими трафіками.

Адміністратори повинні виконати такі дії:

1. Інвентаризація розгортання Apache HTTP Server у виробничих, розробницьких, хмарних та контейнерних середовищах.
2. Ідентифікувати установки, що виконують Apache версій 2.4.55 до 2.4.70.
3. Перевірити, чи завантажено mod_http2.
4. Переглянути глобальні та віртуально-хостові директиви Protocols на наявність h2 або h2c.
5. Оновити розгортання Apache до 2.4.71 або пізнішої версії.
6. Застосувати пакети, специфічні для дистрибуції, коли Apache управляється через Debian, Red Hat, Amazon Linux або інший постачальник операційної системи.
7. Перезапустити Apache після патча, щоб упевнитися, що уразливі процеси робітників більше не працюють.
8. Перевірити ефективну конфігурацію HTTP-сервера після усунення.
9. Переглянути історичну телеметрію на предмет підозрілої активності на інтернет-доступних системах, що були піддані до патчування.

Адміністратори не повинні припускати, що встановлення пакету операційної системи з номером версії нижче 2.4.71 означає, що система залишається уразливою. Постачальники, такі як Red Hat, повертають виправлення безпеки у свої власні версії пакунків, тому відповідну рекомендацію дистрибуції слід розглядати як авторитетну.

Офіційна рекомендація Apache не надає обхідного рішення. Проте, організації, які не можуть одразу застосувати патч, можуть тимчасово видалити HTTP/2 з відкритих конфігурацій, усунувши доступ до відомої уразливої траси коду. Wiz рекомендує обмежити сервер до HTTP/1.1, поки оновлення не буде розгорнуто.

Наприклад:

Protocols http/1.1

Організації, що застосовують цей обхідний шлях, повинні оглянути всі віртуальні хости, оскільки конфігурація сайту може незалежно включати h2 або h2c.

Видалення HTTP/2 може вплинути на продуктивність додатків і поведінку клієнтів, тому зміну слід тестувати й розглядати як тимчасовий захід зниження ризиків, а не заміну для встановлення оновлення безпеки.

Стратегія пом’якшення CVE-2026-119618 повинна також включати зниження непотрібної експозиції. Адміністративні або внутрішні Apache-сервіси, яким не потрібна пряма інтернет-з’єднаність, повинні бути обмежені за допомогою сегментації мережі, балансирів навантаження, зворотних проксі, політик брандмауера або приватних адрес.

Організації, що використовують окремі випуски mod_h2 версій від 2.0.8 до 2.0.42, потребують особливої уваги. Apache вказує ці випуски як такі, що піддаються впливу, тоді як The Hacker News повідомляє, що виправленої окремої версії не було опубліковано на час звіту від 12 листопада. Тимчасове відключення HTTP/2 або міграція на пакет Apache HTTP Server, що містить виправлення, може бути необхідним, поки не буде доступне відповідне окреме оновлення.

Якщо виявлено підозрілу активність, захисники повинні ізолювати уражений сервер, де це можливо операційно, і зберегти журнали доступу Apache, журнали помилок, системні журнали, телеметрію процесу, мережеві з’єднання та належну пам’ять або інформацію про аварії.

Успішну експлуатацію слід розглядати як потенційний злом сервера, а не просто аварію служби. Дослідники мають шукати нові файли, вебшелли, змінений код додатку, механізми збереження стійкості, викрадені облікові дані, підозрілий вихідний трафік та докази бічного руху.

Облікові дані, доступні процесу Apache, включаючи паролі баз даних, ключі API, хмарні облікові дані, приватні ключі TLS або секрети, збережені в конфігурації додатку, повинні бути переглянутими і заміненими, якщо є свідчення про виконання коду, контрольованого зловмисником.