NGINX CVE-2026-42533: перевірте regex map та оновіться

CVE-2026-42533 зачіпає NGINX map із regex-захопленнями. Перевірте небезпечну комбінацію та оновіться до 1.30.4 або 1.31.3.

Дані запиту перевищують виміряний буфер пам’яті NGINX у CVE-2026-42533

CVE-2026-42533 — це heap buffer overflow під час обробки запитів у NGINX. Уразливість може перезапускати worker-процеси, а за певної конфігурації — дозволити віддалене виконання коду без автентифікації. Уразливий код є в NGINX Open Source від 0.9.6 до 1.30.3 включно та в mainline 1.31.2; повне виправлення вийшло у stable 1.30.4 і mainline 1.31.3 [1].

Це не означає, що кожен NGINX-сервер можна негайно зламати. Небезпечний сценарій потребує конфігурації, у якій regex-захоплення та значення map із регулярним виразом обчислюються в проблемному порядку. Оскільки NGINX часто стоїть перед сайтами, API та серверами застосунків, адміністратору потрібно перевірити і версію, і фактичну конфігурацію.

Хто під ризиком

РозгортанняРизик і рішення
NGINX Open Source 0.9.6–1.30.3 або 1.31.2Уразливий код присутній. Оновіться до 1.30.4 або 1.31.3, перевірте конфігурацію та перезавантажте NGINX.
NGINX Plus до виправленого vendor buildЗвіртеся з матрицею F5 та встановіть відповідний виправлений реліз.
Старіша версія з репозиторію дистрибутиваПеревірте security notice постачальника: backport виправлення може зберігати старий номер версії.
Немає взаємодії regex-based map із capturesВідомий trigger може бути відсутнім, але патч прибирає вразливий код і надійніший за припущення, що конфігурація не зміниться.

Чому конфігурація має значення

NGINX формує частину рядків у два проходи: спочатку обчислює потрібний розмір буфера, а потім записує значення. Уразлива взаємодія дозволяє regex-виразу в map перезаписати стан captures між цими проходами. Якщо другий прохід записує більше даних, ніж виміряв перший, worker виходить за межі виділеного heap-буфера.

F5 описує відмову в обслуговуванні через перезапуск worker та можливе виконання коду, якщо ASLR вимкнений або його вдалося обійти [2]. Дослідник Stan Shaw окремо повідомляє про витік heap-вказівників на Ubuntu 24.04, який у його тестах дозволяв обійти ASLR. Це сильніше твердження незалежного дослідження: повний exploit і proof of concept поки не оприлюднені, тому його слід сприймати як причину швидко встановити патч, а не як доказ активної експлуатації [3].

Як перевірити сервер без експлуатації

  1. Зафіксуйте робочу версію. Виконайте nginx -v і перевірте, який саме binary та package обслуговує трафік.
  2. Безпечно виведіть ефективну конфігурацію. Перегляньте результат nginx -T, включно з файлами, підключеними через include.
  3. Шукайте потрібну взаємодію. Пріоритетні блоки поєднують regex captures на кшталт $1 або іменованих груп із regex-based змінною map у спільному шляху побудови рядка.
  4. Перевірте згенеровані конфіги. Hosting panels, ingress controllers, шаблони та deployment automation можуть створити небезпечний порядок поза основним nginx.conf.
  5. Не надсилайте crash або leak-запити на production. Автор дослідження опублікував статичний config scanner, який проходить include-файли та перевіряє передумови без експлуатації сервера.

Безпечний scanner допомагає з triage, але не замінює виправлений binary. До того самого класу обробки ведуть кілька directives, а конфігурації з часом змінюються. Чистий результат перевірки сьогодні не робить непатчений worker безпечним назавжди.

Що зробити зараз

  1. Оновіть NGINX Open Source до 1.30.4 або 1.31.3 чи встановіть відповідний fixed release для NGINX Plus.
  2. Перед reload запустіть nginx -t, а після нього переконайтеся, що нові worker-процеси використовують очікуваний binary.
  3. Навіть після патчу перегляньте regex maps і посилання на captures: простіший порядок обчислення зменшує ризик майбутніх помилок конфігурації.
  4. Перевірте error logs на незрозумілі worker exits, segmentation faults або повторні перезапуски, але не вважайте їх відсутність доказом, що сервер ніколи не був під ризиком.
  5. Якщо публічний сервер підозріло падав до оновлення, збережіть логи та перевірте host на сторонні файли, процеси, облікові дані й persistence, а не покладайтеся лише на перезапуск master process.

Ця помилка відрізняється від NGINX Rift CVE-2026-42945, де небезпечним був інший шаблон rewrite rules і який виправили в попередніх релізах. Тільки травневого оновлення недостатньо для CVE-2026-42533.

Джерела

  1. NGINX. “nginx-1.30.4 stable and nginx-1.31.3 mainline versions released.” NGINX Community Forum, 15 липня 2026 року. Повідомлення про реліз.
  2. NGINX. “Buffer overflow when using map and regex: CVE-2026-42533.” NGINX Security Advisories, дата доступу 19 липня 2026 року. Security advisory.
  3. Stan Shaw. “15-Year-Old Pre-Auth nginx RCE Across 13 Call Sites: Two-Pass Capture Clobbering CVE-2026-42533.” cyberstan, липень 2026 року, дата доступу 19 липня 2026 року. Технічний аналіз.

Пишу про те, як зробити життя онлайн комфортним і безпечним. Вірю, що сучасний цифровий світ вартий того, щоб бути його частиною.