В NGINX Plus і NGINX Open Source виявлено критичну вразливість CVE-2026-42945 (NGINX Rift, CVSS v4 9.2) у модулі ngx_http_rewrite_module, яка залишалася непоміченою протягом 18 років і дає змогу здійснити віддалене виконання коду або відмову в обслуговуванні через неавтентифікований HTTP‑запит; під загрозою опиняються веб‑сервери, reverse‑proxy, ingress‑контролери та WAF на базі NGINX, а адміністраторам необхідно негайно оновити версії або змінити конфігурацію rewrite‑правил, виключивши небезпечні регулярні вирази.

Технічні деталі вразливостей

Початковий дефект NGINX Rift / CVE-2026-42945 виявлено дослідниками проєкту depthfirst і докладно описано в їхньому розборі NGINX Rift. Згідно з повідомленням F5 для клієнтів NGINX (офіційний advisory F5), проблема являє собою переповнення буфера в купі в модулі ngx_http_rewrite_module, що виникає за специфічної комбінації директив і регулярних виразів.

Умова експлуатації CVE-2026-42945 виглядає так:

• використовується модуль ngx_http_rewrite_module із директивою rewrite,
• за нею слідує директива rewrite, if або set,
• у правилах використовуються безіменні PCRE‑захоплення ($1, $2 тощо),
• у рядку заміни присутній символ ?.

Віддалений, неавтентифікований зловмисник, здатний надсилати HTTP‑запити на вразливий сервер, формує спеціально підготовлений URI, що призводить до переповнення купи в процесі worker NGINX. За ввімкненого ASLR це, як мінімум, надійний спосіб спричинити збій і перезапуск worker (відмову в обслуговуванні). За вимкненого ASLR, за оцінкою depthfirst і F5, стає досяжним віддалене виконання коду у контексті процесу NGINX. Див. також запис у NVD: CVE-2026-42945.

Особливість вразливості в тому, що:

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

За даними F5, вразливість зачіпає:

• NGINX Plus R32–R36 (виправлено в R32 P6 і R36 P4);
• NGINX Open Source 1.0.0–1.30.0 (виправлено в 1.30.1 і 1.31.0);
• NGINX Open Source 0.6.27–0.9.7 (виправлень не планується);
• низку продуктів на базі NGINX: NGINX Instance Manager, F5 WAF for NGINX, NGINX App Protect WAF/DoS, NGINX Gateway Fabric, NGINX Ingress Controller — у конкретних діапазонах версій, перелічених в advisory F5.

Додаткові вразливості в NGINX

Одночасно виправлено ще три вразливості середнього та високого рівня небезпеки:

• CVE-2026-42946 (CVSS v4 8.3) — надмірне виділення пам’яті у модулях ngx_http_scgi_module і ngx_http_uwsgi_module. Неавтентифікований зловмисник, який має змогу перехоплювати й модифікувати відповіді upstream‑сервера (adversary-in-the-middle), може сформувати такі відповіді, що NGINX некоректно керує пам’яттю worker‑процесу, що призводить до читання даних із його пам’яті або перезапуску процесу за використання директив scgi_pass або uwsgi_pass. Див. advisory щодо CVE-2026-42946 і запис CVE-2026-42946.
• CVE-2026-40701 (CVSS v4 6.3) — use-after-free у ngx_http_ssl_module. Умова: ssl_verify_client встановлено в on або optional, а ssl_ocsp — в on. Це дає змогу віддаленому неавтентифікованому зловмиснику в обмеженому обсязі модифікувати дані або спричинити перезапуск worker‑процесу. Див. advisory щодо CVE-2026-40701 і CVE-2026-40701.
• CVE-2026-42934 (CVSS v4 6.3) — читання за межами буфера у ngx_http_charset_module. Існує ризик розкриття вмісту пам’яті або перезапуску worker за одночасної конфігурації директив charset, source_charset, charset_map і proxy_pass з вимкненим буферизацією (off). Див. advisory щодо CVE-2026-42934 і CVE-2026-42934.

В оригінальних повідомленнях не йдеться про зафіксовану експлуатацію цих вразливостей у реальних атаках, але технічний профіль CVE-2026-42945 робить її привабливою ціллю для автоматизації та масового сканування.

Контекст і особливості загрози

NGINX традиційно використовується як високонавантажений веб‑сервер і reverse‑proxy, а також як основа ingress‑контролерів у Kubernetes і комерційних рішень F5. Помилка в rewrite‑механізмі, що існувала з ранніх версій (0.6.x), наочно демонструє ризики «прикордонної» логіки: нестандартні комбінації директив, інтеграція з PCRE та складні URI‑шаблони історично тестуються гірше, але активно застосовуються в реальних конфігураціях.

Критично важливо, що вразлива ділянка коду досягається до будь‑яких перевірок автентифікації застосунку або бізнес‑логіки. Фактично NGINX тут виступає як сама поверхня атаки. Це підвищує цінність вразливості для зловмисників: достатньо лише мережевої доступності HTTP‑порту, навіть якщо далі за NGINX приховано добре захищений backend.

Додаткові вразливості (SCGI/UWSGI, SSL, charset) ілюструють інший клас проблем: коли NGINX довіряє вмісту від upstream‑сервера або інфраструктури перевірки сертифікатів (OCSP), помилки обробки цих даних дозволяють вийти за очікувані межі пам’яті. У сценаріях, де зловмисник контролює або може підміняти upstream‑відповіді, такі дефекти перетворюються на потужний інструмент для читання фрагментів пам’яті або відключення сервісів.

Оцінка впливу

Під найбільшим ризиком перебувають:

• організації, що використовують NGINX як публічний веб‑сервер або reverse‑proxy з активним ngx_http_rewrite_module, особливо з великою кількістю складних правил;
• хмарні платформи та хостинг‑провайдери, де один екземпляр NGINX обслуговує багатьох орендарів: успішна експлуатація CVE-2026-42945 може вплинути на всіх клієнтів на цьому вузлі;
• Kubernetes‑кластери з NGINX Ingress Controller, а також інсталяції NGINX App Protect WAF/DoS і NGINX Gateway Fabric у вразливих версіях;
• системи, де ASLR вимкнений або ослаблений (наприклад, спеціалізовані аплайанси чи сильно оптимізовані для продуктивності середовища).

За відсутності заходів реагування можливі такі наслідки:

• повне захоплення вузла через RCE у процесі NGINX (CVE-2026-42945) з подальшим переміщенням всередині мережі;
• компрометація конфіденційних даних за рахунок читання фрагментів пам’яті worker‑процесу (CVE-2026-42946, CVE-2026-42934), де можуть міститися токени, cookie, частини запитів і відповідей;
• широкомасштабна відмова в обслуговуванні — циклічні падіння worker‑процесів, недоступність сайтів і API, зростання затримок і помилок 502/504;
• опосередковані втрати: репутаційні ризики, порушення SLA, можливі штрафи за витік персональних даних.

Практичні рекомендації

1. Пріоритезація та строки

• Розглядати CVE-2026-42945 як критичну: оновлення або застосування обхідного рішення — у пріоритеті «негайно/протягом найближчих годин» на публічно доступних вузлах.
• Інші вразливості (CVE-2026-42946, CVE-2026-40701, CVE-2026-42934) — пріоритет «високий», планувати оновлення в найближче вікно обслуговування.

2. Оновлення до виправлених версій

• Для NGINX Plus оновитися щонайменше до R32 P6 або R36 P4 чи новіших випусків, що містять виправлення (див. advisory F5).
• Для NGINX Open Source — перейти на 1.30.1 або 1.31.0 і вище.
• Для продуктів на базі NGINX (Ingress Controller, App Protect WAF/DoS, Gateway Fabric, Instance Manager, F5 WAF for NGINX) — зіставити поточні версії з діапазонами, зазначеними у відповідних advisory F5, і оновитися до рекомендованих релізів.
• Для дуже старих гілок 0.6.27–0.9.7, де виправлень не планується, єдиний шлях — міграція на підтримувані версії.

3. Обхідне рішення для CVE-2026-42945

Якщо негайне оновлення недоступне, рекомендується змінити конфігурацію rewrite‑правил, як описано F5 і depthfirst:

• Знайти всі директиви rewrite, за якими слідує rewrite, if або set, де:
  • використовуються безіменні захоплення виду $1, $2 тощо;
  • у рядку заміни присутній символ ?.
• Переписати регулярні вирази з використанням іменованих захоплень PCRE, наприклад:
  • було: rewrite ^/user/(\d+)\?(.*)$ /profile.php?id=$1?$2;
  • стало: rewrite ^/user/(?<uid>\d+)\?(?<rest>.*)$ /profile.php?id=$uid?$rest;
• Переконатися після змін, що функціональність перенаправлень зберігається, і перезапустити NGINX.

Суть обходу: переведення безіменних захоплень в іменовані змінює шлях обробки даних у коді NGINX і виключає вразливий сценарій.

4. Зниження ризику за додатковими вразливостями

До оновлення можна тимчасово скоротити поверхню атаки:

• Для CVE-2026-42946: за можливості обмежити або тимчасово вимкнути scgi_pass і uwsgi_pass на зовнішніх межах, особливо там, де upstream може бути під контролем третіх осіб.
• Для CVE-2026-40701: за невисокої критичності перевірки клієнта й OCSP розглянути тимчасове вимкнення ssl_ocsp on або послаблення ssl_verify_client, оцінивши при цьому вплив на вимоги до автентифікації клієнта.
• Для CVE-2026-42934: мінімізувати використання charset_map у поєднанні з proxy_pass і вимкненою буферизацією, якщо це можливо без шкоди для бізнесу.

5. Перевірка вразливості та моніторинг

• Перевірити версію NGINX командою nginx -v і зіставити з діапазонами вразливих версій.
• Проаналізувати конфігурацію:
  • пошук по nginx.conf та підключених файлах за ключами rewrite, $1, $2, ?;
  • виокремити правила, що відповідають описаному вище патерну.
• Увімкнути або посилити логування помилок NGINX і системне логування:
  • звертати увагу на повторювані падіння worker‑процесів, сигнали segmentation fault, циклічні перезапуски;
  • зіставляти ці події з підозрілими HTTP‑запитами, що містять нестандартні URI з ? і складними патернами.
• Переконатися, що на серверах увімкнено ASLR на рівні операційної системи як додатковий рубіж захисту від RCE, навіть після встановлення патчів.

Ключова дія для власників інфраструктури на базі NGINX — у найкоротші строки оновити NGINX Plus, NGINX Open Source і пов’язані продукти до версій із виправленнями CVE-2026-42945 та супутніх вразливостей, а за затримок з оновленням негайно провести ревізію rewrite‑правил із заміною безіменних захоплень на іменовані в усіх конфігураціях, доступних з інтернету.