sber
Не сто резюме, а сто друзей: почему рекомендации снова стали валютой рынка труда
РМИАЦ Бурятии запустил отказоустойчивый кластер на базе РЕД ВИРТ
Свыше тысячи школ Уральского ФО выбрали ОС Astra Linux для цифровизации образования
Иван Хрулев, «Группа Астра»: «Astra Automation – уникальная на российском рынке платформа по спектру возможностей»
КПД ИИ-контура: новая метрика для CIO
ЦБ
°
вторник, 18 августа 2026

«18 мне уже»: давний критический баг угрожает публичным веб-сервисам

«18 мне уже»: давний критический баг угрожает публичным веб-сервисам
Изображение: Газинформсервис
Критическая уязвимость в HTTP-сервере NGINX активно эксплуатируется злоумышленниками, об этом сообщают СМИ со ссылкой на данные исследователей. Владислав Шелепов, аналитик угроз GSOC компании «Газинформсервис», объяснил, в чём опасность этой уязвимости и что можно сделать компаниям на данном этапе.

«Уязвимость CVE-2026-42945 находится в том самом слое, который у многих компаний первым принимает HTTP-запрос снаружи: reverse proxy, балансировщик, ingress в Kubernetes, фронт для внутренних сервисов — всё это может содержать уязвимый NGINX. Для эксплуатации есть условия, нужен конкретный паттерн rewrite-конфигурации: неименованные PCRE-захваты вроде $1, $2, знак вопроса в строке замены и следующая директива rewrite, if или set. При отключённом ASLR появляется риск RCE, но даже с включённой рандомизацией у атаки остаётся неприятный эффект — падение worker-процессов и деградация доступности для публичного NGINX, который держит входной трафик к нескольким сервисам, а это уже серьёзный ущерб», — пояснил эксперт. 

Отметим, что проблема затрагивает все версии NGINX от 0.6.27 до 1.30.0 и существовала в коде около 18 лет.

По словам эксперта, компаниям рекомендуется предпринять следующие шаги:

— найти все экземпляры NGINX, проверить версии и конфиги rewrite, обновиться до исправленных релизов, а если патч сразу невозможен — временно заменить неназванные захваты (например $1, $2) на именованные;
— отдельно стоит проверить ASLR, потому что при отключённой рандомизации появляется риск RCE;
— если используется WAF, имеет смысл добавить правила на подозрительные URI и нестандартные последовательности запросов, которые попадают в уязвимые rewrite-маршруты;
— и последняя рекомендация — использовать услуги центра мониторинга, например GSOC компании «Газинформсервис». SOC поможет настроить мониторинг, проверить периметр, проверить ретроспективу по логам и сопроводить митигацию до закрытия уязвимости.

Свежее по теме