CVE-2025-1974 — IngressNightmare (ingress-nginx)

Введение

В данном документе представлено исследование уязвимости CVE-2025-1974, затрагивающей компонент ingress-nginx (validating admission controller) для Kubernetes.
CVE-2025-1974 — критическая уязвимость (CVSS 3.1 9.8), представляющая собой unauthenticated Remote Code Execution (RCE) в контексте процесса ingress-nginx. При выполнении атаки злоумышленник, имеющий доступ к pod-сети (или способ доставить AdmissionReview к validating webhook), может добиться выполнения произвольного кода в pod’е контроллера, что потенциально ведёт к раскрытию Secrets и захвату кластера.

Ingress-nginx — один из самых распространённых контроллеров Ingress в Kubernetes (оценки показывали использование в десятках процентов кластеров), поэтому практический импакт уязвимости очень высок. Описание, технический анализ и официальные рекомендации по фиксам опубликованы Kubernetes, исследователями Wiz и рядом вендор-блогов.

Цель отчёта

Пошагово разобрать CVE-2025-1974 и подготовить материалы, необходимые для write-up:

Сбор и структурирование материалов. Собрать официальные advisories, исследовательские write-ups и vendor-аналитику; выделить ключевые технические детали и PoC-направления.
Понять суть уязвимости и её импакт. Объяснить root cause, атак-цепочку и возможные последствия (RCE → disclosure of Secrets → cluster takeover).
Определить CPE и условия конфигурации. Перечислить версии/пакеты и конфигурации Kubernetes/ingress-nginx, при которых уязвимость актуальна.
Дать рекомендации по безопасному тестированию в лабе и минимизации риска при массовой проверке.

⚠️ Дисклеймер

Данное исследование проводится исключительно в образовательных и этичных целях и ориентировано на тестовые/контролируемые среды.
Ни при каких условиях не запускать эксплойты/PoC против чужих кластеров или публично-доступных инстансов без письменного разрешения владельца. Публикация полностью рабочей «weaponized» PoC в открытом виде сильно повышает риск злоупотреблений — в публичной части лучше приводить safe-PoC и методологию. (Официальные advisories и вендоры также подчёркивают осторожность при распространении эксплойтов).

CPE и условия конфигурации

cpe:2.3:a:kubernetes:ingress-nginx_controller:<version> — уязвимые версии ingress-nginx (в advisories указаны конкретные версии; обновите значения при финальной публикации).
Поставщики/дистрибутивы, включающие уязвимый контроллер:
- RKE2 / Rancher дистрибутивы с ingress-nginx до указанных патч-версий.
- Harvester версии, использующие уязвимый ingress-nginx (вендор-KB содержит конкретные affected builds).
- Пользовательские кластеры, где ingress-nginx установлен отдельно (Helm chart/manifest) — проверять версии chart/image.

Условия конфигурации, при которых уязвимость актуальна:

Уязвимая версия ingress-nginx (до релиза/патча, указанного в advisories). Точные номера версий см. в NVD и вендорских advisories.
Validating admission webhook доступен снаружи pod-сети — если webhook доступен извне (например, публичный endpoint, провайдер ошибочно пробросил сервис), эксплойт может быть выполнен удалённо. Wiz и другие исследователи указывали на многочисленные случаи публичного экспонирования.
Отсутствие NetworkPolicy / изоляции pod-сети: если злоумышленник может отправлять запросы из какого-либо pod’а в кластер-сеть (compromised pod), это достаточно для эксплуатации.
Отсутствие дополнительных валидаций/ACL перед admission controller: дополнительные фильтры/ingress-proxy аутентификации могут снижать риск.
Наличие в контейнере ingress-nginx сервис-аккаунта с широкими правами и доступом к Secrets — по умолчанию контроллер часто монтирует serviceAccount с широкими правами; это увеличивает импакт при успешной эксплуатации.

Подробности уязвимости

Краткое резюме.
Уязвимость обнаружена в компоненте Validating Admission Controller контроллера Ingress-NGINX и связана с тем, как этот компонент формирует и проверяет временную конфигурацию NGINX на основе входящих Ingress / AdmissionReview. В процессе обработки контроллер генерирует nginx.conf и запускает проверку конфигурации (nginx -t). При недостаточной санитизации полей Ingress/AdmissionReview атакующий может подставить специально подготовленные фрагменты, которые попадут в сгенерированный конфиг и в результате приведут к выполнению команд внутри процесса контроллера — то есть к удалённому выполнению кода (RCE) в pod’е ingress-nginx.

Основные технические моменты

Точка входа. Входящие AdmissionReview/Ingress объекты, принимаемые validating webhook контроллера, становятся исходными данными для генерации конфигурации NGINX (включая поля аннотаций, backend-настройки и пр.).
Механизм эксплуатации. Сформированный злонамеренный Ingress или прямой AdmissionReview может внедрить управляемые строки в шаблоны/фрагменты конфигурации. При проверке/загрузке такого nginx.conf процесс проверки (nginx -t) и последующие операции с файлом конфигурации могут привести к исполнению произвольного кода, записи/запуску файлов или запуску команд в контексте контроллера.
Необходимые условия. Для успешной эксплуатации требуется: уязвимая версия ingress-nginx; возможность доставить AdmissionReview до validating webhook (доступ из pod-сети или прямой сетевой доступ); отсутствие компенсирующих мер — NetworkPolicy, RBAC-ограничений или дополнительной аутентификации webhook. В ряде сценариев обход прав Create/Update возможно путём отправки crafted AdmissionReview напрямую к webhook.

admission

Чем это опасно — последствия эксплуатации

Успешная эксплуатация даёт исполнение кода в контейнере ingress-nginx, что, как правило, позволяет:

получить токен serviceAccount контроллера и обратиться к Kubernetes API;
читать Secrets и другую конфиденциальную информацию в доступных namespace’ах;
создавать/изменять ресурсы кластера и расширить доступ (эскалация привилегий, lateral movement);
в ряде случаев — полный захват кластера.

Поведенческие и детекционные наблюдения

При корректной работе контроллера потоков запросов к Admission Controller обычно нет — validating webhook служит внутренним компонентом, работающим в пределах кластера. Во время эксплуатации наблюдается аномалия: на сетевой карте (например, Luntry) появление входящих соединений к ingress-nginx-controller-admission и сервису ingress-nginx-controller от нестандартных источников (в репортах — от контейнеров типа alpine), чего при нормальной работе не должно быть.
Анализ сетевой карты кластера даёт представление о взаимодействиях между микросервисами; выбрав Deployment ingress-nginx в неймспейсе, можно увидеть входящие/исходящие связи. Появление входящих соединений к admission-endpoint в момент атаки — явный индикатор компрометации.
Для обнаружения попыток эксплуатации полезно мониторить: POST-запросы к validating webhook, создание атипичных Ingress-объектов, вызовы nginx -t и внезапные перезапуски контроллера, а также неожиданные операции записи файлов от процесса ingress-nginx.

Контекст: что такое Ingress-контроллер NGINX и почему он важен

Ingress-NGINX — один из наиболее широко используемых контроллеров Ingress в Kubernetes (широко применяется для организации внешнего доступа к сервисам). Контроллер выступает как обратный прокси: принимает внешний трафик и проксирует его к соответствующим Service/Pod на основе набора правил Ingress. Проект Ingress-NGINX пользуется большой популярностью и имеет значительную долю установки в интернет-доступных кластерах.

Ingress-NGINX в документации Kubernetes приводится как эталонный пример контроллера Ingress. По оценкам, значительная доля открытых кластеров применяют именно его; в некоторых исследованиях указывается, что порядка 41% публично доступных кластеров используют Ingress-NGINX. Именно из-за широкой распространённости и центральной роли в маршрутизации трафика уязвимости в этом компоненте имеют высокий практический импакт.

Почему validating webhook становится удобным вектором атаки

По умолчанию validating webhook контроллера доступен внутри сетевого пространства Kubernetes и зачастую не требует дополнительной аутентификации при обращении на его адрес (например, validate.nginx.ingress.kubernetes.io). Это делает его лёгким для обращения изнутри кластера.
Комбинация: широкое распространение контроллера + его сетевой доступ + потенциально широкие права сервис-аккаунта = критическая комбинация, обеспечивающая эффективный путь для компрометации.
В реальной практике получить «первую точку входа» в кластер не так трудно: приложения часто содержат уязвимости, приводящие к компрометации отдельного контейнера; далее атакующий из этого контейнера может обратиться к internal webhook-ам. Кроме того, exploitable уязвимости типа SSRF в веб-приложениях часто используются, чтобы инициировать запросы внутрь кластерной сети и задействовать такие webhook.

Повторное описание exploit-цепочки (конспективно)

Атакующий получает возможность отправлять запросы в pod-сеть или напрямую обращаться к validating webhook.
Формируется специально crafted Ingress / AdmissionReview, где определённые поля содержат вредоносные строки, не прошедшие надлежащую фильтрацию.
Контроллер генерирует nginx.conf на основе этих входных данных и выполняет nginx -t / другие операции проверки.
Внедрённые фрагменты приводят к выполнению команд/скриптов или записи/запуску файлов в контексте процесса контроллера.
Получив исполнение, злоумышленник извлекает serviceAccount token, обращается к Kubernetes API и продолжает перемещение и эскалацию в кластере.

Замечания по совместимости с другими уязвимостями

Такие уязвимости особенно опасны в связке с другими дефектами: компрометированный pod (или SSRF в публичном приложении) + экспонированный validating webhook даёт высокий шанс полного взлома. Поэтому анализ инцидентов должен учитывать цепочку зависимостей и потенциальных векторов, а не только версию ingress-nginx.

CVE-2025-1974

Популярное