Михаил Гаца
DevOps-инженер
Средняя
В мае 2026 года была опубликована критическая уязвимость CVE-2026–42945, получившая неофициальное название NGINX Rift. Проблема затрагивает обработку rewrite-правил в NGINX и при определённых условиях может привести к heap overflow с последующим выполнением произвольного кода (RCE).
Учитывая широкое распространение NGINX в качестве reverse proxy, ingress-контроллера и API gateway, уязвимость вызвала значительный интерес со стороны специалистов по информационной безопасности и эксплуатации инфраструктуры.
Содержание
Суть уязвимости
Проблема находится в модуле `ngx_http_rewrite_module` и связана с обработкой rewrite-конструкций, использующих regex-captures `$1`, `$2` и т.д.) совместно с query-параметрами.
Наиболее опасным считается следующий паттерн:
rewrite ^/user/(.*)$ /profile?u=$1;
В определённых сценариях специально сформированный HTTP-запрос приводит к некорректной обработке памяти внутри rewrite engine. Эксплуатация осуществляется обычным HTTP/HTTPS-запросом и не требует аутентификации.
Важно понимать, что HTTPS не является защитой от данной уязвимости. TLS обеспечивает только шифрование транспортного канала, однако после TLS termination запрос продолжает обрабатываться NGINX, включая rewrite-логику.
Какие конфигурации подвержены риску?
На практике уязвимость проявляется не во всех конфигурациях NGINX, а только при наличии определённых комбинаций:
- использования `rewrite`, `if` или `set`;
- regex-captures `$1`, `$2`, …);
- передачи значений через `?query=`;
- сложных rewrite-chain внутри одного request flow.
Например:
rewrite ^/api/(.*)$ /internal?id=$1;
или
set $user_id $1;
в сочетании с rewrite-логикой.
Особенно часто подобные конструкции встречаются:
- в legacy-конфигурациях;
- ingress-nginx;
- OpenResty;
- старых PHP migration routing rules;
- API gateway и SSO proxy;
- SEO rewrite-конфигурациях.
Использование NGINX в Нетопии
В инфраструктуре Нетопии NGINX используется исключительно в качестве reverse proxy и балансировщика трафика.
Наша конфигурация не использует потенциально опасные rewrite-комбинации, связанные с unnamed regex captures `$1`, `$2`) и query-rewrite логикой вида:
rewrite ^/user/(.*)$ /profile?u=$1;
По результатам внутреннего аудита:
- у нас отсутствуют уязвимые rewrite-chain;
- не используются legacy rewrite-сценарии;
- отсутствует динамическая URI-трансформация через regex captures;
- маршрутизация реализована через статические `location`-блоки и proxy_pass.
Таким образом, опубликованная уязвимость не затронула инфраструктуру компании. Тем не менее, после публикации CVE-2026-42945 были дополнительно проведены:
- аудит nginx-конфигураций;
- проверка ingress-конфигураций;
- контроль наличия `$1/$2` captures;
- ревизия контейнерных образов и Helm charts.
Как быстро проверить наличие уязвимых конструкций?
Для оперативной диагностики внутри контейнера или Kubernetes pod достаточно выполнить поиск по nginx-конфигурациям.
Проверка внутри контейнера
grep -R «rewrite» /etc/nginx 2>/dev/null
grep -R «\$1» /etc/nginx 2>/dev/null
grep -R «\$2» /etc/nginx 2>/dev/null
grep -R «set » /etc/nginx 2>/dev/null
Быстрая проверка на потенциально опасные rewrite-конструкции
grep -R «rewrite .*?\?.*\$[0-9]» /etc/nginx 2>/dev/null
Данная команда позволяет быстро обнаружить наиболее рискованные паттерны, где regex-captures передаются в query string.
Проверка внутри Kubernetes pod
kubectl exec -it <pod-name> — sh
После подключения:
grep -R «rewrite .*?\?.*\$[0-9]» /etc/nginx 2>/dev/null
Либо одной командой:
kubectl exec <pod-name> — \
grep -R «rewrite .*?\?.*\$[0-9]» /etc/nginx 2>/dev/null
Проверка всех ingress-nginx pod
kubectl get pods -A | grep nginx
Далее:
kubectl exec -n <namespace> <pod-name> — \
grep -R «\$1» /etc/nginx 2>/dev/null
Рекомендации по снижению рисков
Даже если инфраструктура не использует уязвимые конструкции, рекомендуется:
- обновить NGINX до исправленных версий;
- минимизировать использование rewrite-логики;
- отказаться от unnamed captures `$1`, `$2`) в пользу named captures;
- избегать сложных regex rewrite-chain;
- использовать `try_files`, `map` и статические location-блоки;
- ограничить размер URI и query string;
- контролировать crash-loop и worker restart события.
Дополнительно рекомендуется регулярно проводить аудит ingress-конфигураций и container image scanning, поскольку уязвимые шаблоны могут попадать в инфраструктуру через сторонние Helm charts или legacy deployment templates.
Заключение
CVE-2026–42945 стала показательным примером того, насколько опасными могут быть сложные rewrite-конфигурации в высоконагруженной инфраструктуре.
Несмотря на то, что у нас в Нетопии уязвимость не затронула production-среду благодаря консервативному использованию NGINX как reverse proxy, публикация CVE послужила дополнительным поводом для ревизии конфигураций и hardening-практик.
Главный вывод заключается в том, что безопасность reverse proxy определяется не только версией программного обеспечения, но и архитектурной дисциплиной конфигурации.
Адрес:
121205, г. Москва, муниципальный округ Можайский, территория инновационного центра «Сколково», б-р Большой, д. 42, стр. 1, этаж 2, помещение № 162/№ 4
Телефон:
+7 (495) 255-35-82
Почта:
info@netopia.pro
Деятельность осуществляется компанией ООО «Нетопия» при грантовой поддержке Фонда «Сколково»
© Netopia.pro
