Критична вразливість CVE-2026-42945 в NGINX Plus і NGINX Open, що дозволяє спричинити відмову в обслуговуванні або за певних умов виконати довільний код, за даними компанії VulnCheck, уже експлуатується зловмисниками — буквально за кілька днів після публічного розкриття. Паралельно зафіксовано атаки на три критичні вразливості в openDCIM, які поєднуються в ланцюжок для отримання віддаленого виконання коду. Організаціям, що використовують ці продукти, необхідно негайно оцінити свою підверженість і застосувати доступні виправлення.

CVE-2026-42945: переповнення буфера в NGINX

Вразливість CVE-2026-42945 являє собою переповнення буфера в купі (heap buffer overflow) у модулі ngx_http_rewrite_module. Як повідомляється, уразливими є версії NGINX з 0.6.27 по 1.30.0. Успішна експлуатація дає змогу неавтентифікованому атакувальнику за допомогою спеціально сформованих HTTP-запитів спричинити аварійне завершення робочих процесів (worker processes), що призводить до відмови в обслуговуванні.

Можливість віддаленого виконання коду (RCE) існує, однак вимагає одночасного виконання кількох умов. Дослідник безпеки Кевін Бомонт зазначив, що для експлуатації потрібна певна конфігурація NGINX, яку атакувальник має знати або виявити, а для досягнення RCE на цільовій системі має бути вимкнений механізм ASLR (Address Space Layout Randomization).

Реалістична оцінка загрози

Мейнтейнери AlmaLinux у своєму аналізі надали зважену оцінку: перетворити переповнення буфера в купі на надійне виконання коду нетривіально за типової конфігурації, а на системах з увімкненим ASLR (що є налаштуванням за замовчуванням у всіх підтримуваних випусках AlmaLinux) створення універсального й надійного експлойта видається вкрай утрудненим. Втім, як підкреслили мейнтейнери, «нетривіально» не означає «неможливо», а сценарій відмови в обслуговуванні через аварійне завершення робочих процесів цілком реалістичний сам по собі, щоб розглядати цю вразливість як невідкладну.

Ця оцінка принципово важлива для правильної пріоритизації. Організації, в яких ASLR вимкнений з тих чи інших причин (застарілі системи, специфічні вимоги сумісності), перебувають у зоні значно вищого ризику. Для решти основна загроза — це DoS-атака, яка, утім, може завдати серйозної шкоди за використання NGINX як зворотного проксі-сервера або балансувальника навантаження на критичних сервісах.

За даними VulnCheck, спроби експлуатації вже зафіксовано в їхній мережі пасток (honeypot). Цілі та характер атакувальної активності наразі не встановлені.

Ланцюжок вразливостей openDCIM: від SQL injection до зворотної оболонки

Паралельно VulnCheck повідомила про експлуатацію двох критичних вразливостей у openDCIM — застосунку з відкритим вихідним кодом для управління інфраструктурою центрів обробки даних:

• CVE-2026-28515 (CVSS 9.3) — відсутність перевірки авторизації, що дає змогу автентифікованому користувачеві отримати доступ до функціональності конфігурації LDAP незалежно від наданих привілеїв. У розгортаннях на базі Docker, де змінну REMOTE_USER задано без примусової автентифікації, кінцева точка може бути доступною без облікових даних, що відкриває можливість несанкціонованої зміни конфігурації застосунку.
• CVE-2026-28517 (CVSS 9.3) — command injection у компоненті report_network_map.php. Параметр dot передається в команду оболонки без санітизації, що призводить до можливості виконання довільного коду.
• CVE-2026-28516 (CVSS 9.3) — SQL injection в openDCIM.

Усі три вразливості були виявлені дослідником безпеки VulnCheck Валентином Лобштейном у лютому 2026 року. Згідно з його технічним описом, три вразливості можуть бути об’єднані в ланцюжок для досягнення віддаленого виконання коду за п’ять HTTP-запитів із подальшим запуском зворотної оболонки (reverse shell). Це робить ланцюжок атаки практично повністю автоматизованим.

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

Масштаб потенційного впливу вразливості NGINX визначається повсюдним поширенням цього вебсервера: його використовують мільйони сайтів і сервісів у всьому світі як вебсервер, зворотний проксі та балансувальник навантаження. Навіть якщо сценарій RCE важко досяжний, DoS-атака на робочі процеси NGINX може призвести до каскадних відмов сервісів, що розміщені за ним. Особливо вразливі організації з нестандартними конфігураціями модуля перезапису та застарілими системами без ASLR.

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

Рекомендації щодо захисту

Для NGINX

• Установіть останні оновлення від F5 для NGINX Plus і NGINX Open, які усувають CVE-2026-42945.
• Переконайтеся, що ASLR увімкнений на всіх серверах з NGINX — це значно ускладнює експлуатацію RCE-сценарію.
• Проведіть аудит конфігурацій ngx_http_rewrite_module — для експлуатації вразливості потрібна певна конфігурація.
• Розгляньте впровадження WAF-правил для виявлення аномально сформованих HTTP-запитів, націлених на модуль перезапису.
• Моніторте аварійні завершення робочих процесів NGINX як потенційний індикатор спроб експлуатації.

Для openDCIM

• Перевірте наявність оновлень openDCIM, що усувають CVE-2026-28515, CVE-2026-28516 і CVE-2026-28517.
• У розгортаннях на Docker переконайтеся, що змінну REMOTE_USER не задано без належного механізму автентифікації.
• Обмежте мережевий доступ до openDCIM — застосунок не повинен бути доступним з інтернету.
• Перевірте сервери на наявність нетипових PHP-файлів, які можуть бути вебоболонками, встановленими в ході компрометації.

Обидві групи вразливостей вимагають негайного реагування: для NGINX — пріоритетне оновлення та перевірка конфігурації ASLR, для openDCIM — оновлення та ізоляція від зовнішнього доступу. З огляду на підтверджену активну експлуатацію обох продуктів і наявність автоматизованих інструментів атаки, вікно для безпечного встановлення патчів стрімко звужується.