Критическая уязвимость 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-инъекции до обратной оболочки

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

• CVE-2026-28515 (CVSS 9.3) — отсутствие проверки авторизации, позволяющее аутентифицированному пользователю получить доступ к функциональности конфигурации LDAP вне зависимости от назначенных привилегий. В развёртываниях на базе Docker, где переменная REMOTE_USER установлена без принудительной аутентификации, конечная точка может быть доступна без учётных данных, что открывает возможность несанкционированного изменения конфигурации приложения.
• CVE-2026-28517 (CVSS 9.3) — инъекция команд операционной системы в компоненте report_network_map.php. Параметр dot передаётся в команду оболочки без санитизации, что приводит к возможности выполнения произвольного кода.
• CVE-2026-28516 (CVSS 9.3) — SQL-инъекция в 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 — обновление и изоляция от внешнего доступа. Учитывая подтверждённую активную эксплуатацию обоих продуктов и наличие автоматизированных инструментов атаки, окно для безопасного патчинга стремительно сокращается.