Новые уязвимости в Ingress-nginx для Kubernetes позволяют хакерам удаленно выполнять произвольный код

Недавно эксперты компании Wiz обнаружили пять критических уязвимостей (IngressNightmare) в контроллере Ingress Nginx — ключевом компоненте Kubernetes, который выполняет функции балансировщика нагрузки и обратного прокси. Эти уязвимости позволяют злоумышленникам удаленно выполнять произвольный код (RCE) и захватывать контроль над кластерами.

Про Ingress-nginx 

Ingress-nginx – это, по сути, «диспетчер» входящего в кластер трафика. Он управляет доменами, маршрутизирует входящие запросы, балансирует нагрузку, и обрабатывает ssl/tls-соединения и т.д. Контроллер позволяет внешнему миру связываться с приложениями, которые работают в кластере.

Nginx используется в качестве ревёрс-прокси, управляя входящим трафиком. Контроллер ingress-nginx анализирует URL и заголовки запроса, сверяя их с правилами, описанными в объекте Ingress.

Примеры:

• example.com/api -> направляется в один сервис

• example.com/web -> направляется в другой сервис

Здесь nginx создает внутри контроллера динамическую конфигурацию, которая позволяет ему перенаправлять трафик нужным приложениям.

Про уязвимости IngressNightmare

Несколько дней назад были опубликованы пять уязвимостей, связанных с контроллером ingress-nginx:

• CVE-2025-1974 (9.8 Critical) — позволяет неавторизованному пользователю произвести удаленное выполнение кода

• CVE-2025-24514 (8.8 High) — дает возможность выполнить инъекцию конфигурации через аннотацию auth-url из-за отсутствия санитизации данных запроса

• CVE-2025-1097 (8.8 High) — позволяет осуществить инъекцию конфигурации через аннотацию auth-tls-match-cn из-за отсутствия санитизации данных запроса

• CVE-2025-1098 (8.8 High) — позволяет выполнить инъекцию конфигурации через аннотацию mirror-target и mirror-host из-за отсутствия санитизации данных запроса

• CVE-2025-24513 (4.8 Medium) — позволяет получить доступ к файлам и папкам, находящимся за пределами корневой директории

В статье-разборе опубликованных CVE в официальном блоге Kubernetes говорится, что 40% всех Kubernetes-кластеров используют контроллер Ingress-nginx. Сложно определить точное количество уязвимых кластеров, однако на момент публикации информации об уязвимостях в поисковой системе Shodan было найдено около 4,4 тыс. кластеров, которые могли быть потенциально уязвимы. 

Контроллер Ingress-nginx является одним из самых популярных, он обладает большим функционалом и огромной поддержкой сообщества. Для эксплуатации уязвимости удаленно через интернет требуется выполнение довольно специфических условий, что значительно снижает вероятность успешной атаки без проникновения в сеть кластера. Поэтому количество уязвимых кластеров значительно больше, но уровень критичности в этом случае ниже, так как эксплуатация возможна, только если злоумышленник проникнет в сеть кластера Kubernetes.

Как неавторизованный злоумышленник может запустить произвольный код 

В основной и самой критической уязвимости CVE-2025-1974 проблема заключается в коде тестирования предоставляемого файла конфигурации для nginx. CVE-2025-1974 позволяет злоумышленнику внедрить произвольные директивы в конфигурацию nginx, которые впоследствии будут проверены командой nginx -t. Это не сразу приводит к выполнению кода — если удастся найти в nginx -t директиву, выполняющую произвольный код, это приведет к компрометации пода (pod — минимальная сущность в k8s, представляющая собой группу из одного или нескольких контейнеризированных приложений) и получению им высокопривилегированной роли Kubernetes. Важно отметить, что конфигурация nginx только тестируется и не применяется, что сокращает количество директив, которые можно реально использовать. 

Самым удобным и работоспособным оказался вариант с директивой ssl_engine, которая является частью модуля OpenSSL и позволяет загружать разделяемые библиотеки. В этом случае необходимо отправить на сервер запрос с содержимым разделяемой библиотеки, в которой находится код для подключения к нашей удаленной консоли. В запросе можно использовать заголовок с размером содержимого и указать немного больше, чем размер файла, чтобы nginx не разрывал соединение и ждал. Это делается для того, чтобы технология кэширования nginx сохранила передаваемый файл в ProcFS, после чего мы можем загрузить его из /proc/, и код нашей удаленной консоли выполнится.

Если злоумышленник успешно проэксплуатирует уязвимость и попадет в под ingress-nginx контроллера, он сможет читать секреты во всех пространствах кластера. Там могут содержаться приватные данные, ключи, сертификаты и т.д. Злоумышленник может повысить свои права до администратора кластера и полностью его захватить.

Может ли отключение Validating Admission Controller защитить систему?

Validating Admission Controller — это механизм, который проверяет входящие запросы на создание, обновление или удаление ресурсов в кластере. Он действует как «финальная проверка» перед тем, как запрос будет применен. Выглядит это примерно так:

1. Пользователь или сервис отправляет запрос на создание или изменение ресурса (например, пода, деплоймента).

2. API-сервер Kubernetes отправляет этот запрос на проверку в Validating Admission Controller.

3. Контроллер анализирует запрос и решает:

   • Разрешить его (если всё соответствует политикам безопасности и корректности)

   • Отклонить его (если нарушены правила)

4. Только после успешной проверки запрос выполняется, и ресурс создается или обновляется.

Если отключить эту функцию, проверка конфигурации не будет выполняться. Поэтому это решение можно рассматривать только как временную меру.

Как защитить Kubernetes-кластеры

Для начала, разумеется, необходимо проверить, что порт, на котором работает вебхук контроллера, доступен исключительно внутри кластера и не торчит наружу. Лучшим решением будет обновление продукта, так как разработчики уже выпустили обновление, в котором были исправлены эти уязвимости. Но если возможности обновиться нет, можно произвести перестановку контроллера, отключив при этом вебхук controller.admissionWebhooks.enabled=false. Однако это исключительно временное решение.

Для своевременного реагирования необходимо иметь мониторинг и собирать метрики с контроллеров (запросы, ошибки и другое). Также в кластере необходимо иметь средство для организации безопасности. Это могут быть Kyverno или Gatekeeper, которые позволяют внедрять гибкие политики для нагрузок. В инструменте Tetragon есть возможность отлавливать системные вызовы и запрещать запуск нагрузок, что позволяет защититься от ещё не обнаруженных уязвимостей.

Последствия 

Успешная эксплуатация уязвимостей IngressNightmare может привести к утечке конфиденциальных данных, включая персональную информацию клиентов. В худшем случае, возможен захват кластеров, что позволит злоумышленникам изменять или удалять критически важные данные. Также существует риск вывода сервисов из строя, что приведет к значительным финансовым и репутационным потерям и может негативно сказаться на лояльности клиентов.