Кластеры Kubernetes, где доступ к сервисам закрывают внешней аутентификацией, получили проблему в NGINX Ingress Controller. В версиях с 5.6.0 по 5.6.3 контроллер неверно разбирает ответ внешнего поставщика удостоверений и передаёт запрос приложению раньше, чем проверка успевает завершиться. Значит, удалённый злоумышленник без учётных данных попадает на защищённые маршруты. Уязвимость зарегистрирована как CVE-2026-104939 и получила рейтинг High: 7.5 по CVSS v3.1 и 8.7 по CVSS v4.0.
Уязвимость CVE-2026-104939 во внешней аутентификации NGINX Ingress Controller
Речь о политике externalAuth, то есть о внешней аутентификации. Контроллер входа (Ingress Controller) принимает трафик извне и распределяет его по сервисам кластера. Когда политика включена, каждый запрос сначала уходит на проверку к внешнему поставщику удостоверений, обычно работающему по протоколу OAuth.
Схема простая. Поставщик отвечает контроллеру, тот разбирает ответ и решает, пропускать ли пользователя дальше. Ошибка в этой логике классифицирована как CWE-303, некорректная реализация алгоритма аутентификации. Контроллер трактует ответ неверно и открывает маршрут до того, как внешняя проверка состоялась.
Под защищёнными путями здесь понимаются адреса, доступ к которым разрешён только после успешного входа. Обычно так закрывают панели управления, внутренние API, административные интерфейсы и служебные разделы приложений. Проверку прав в такой схеме выполняет не само приложение, а поставщик удостоверений на стороне. Поэтому сбой в контроллере обесценивает всю защиту целиком: приложение уверено, что запрос уже прошёл проверку.
Плоскость управления кластером при этом не затронута, проблема лежит в плоскости данных. Настройки самого Kubernetes под угрозой не находятся, зато доступ к приложениям, закрытым внешней аутентификацией, теряет защиту. Эксплуатация не требует учётных данных и предварительного доступа к сети: достаточно отправить запрос на уязвимый контроллер.
Список уязвимых сборок узкий. Проблема затрагивает ветку 5.x в версиях с 5.6.0 по 5.6.3, тогда как ветка LTS, а также ветки 4.x и 3.x в него не входят. Другие продукты вендора, включая BIG-IP, F5OS и облачные сервисы, под эту уязвимость не попадают. Поэтому круг пострадавших ограничен кластерами с конкретными версиями контроллера, где включена внешняя аутентификация.
Рейтинг High отражает характер ошибки: проверка обходится полностью, а не частично, и подготовка к атаке минимальна. Для организаций, которые публикуют сервисы через такой контроллер, это оборачивается доступом к закрытым маршрутам без входа в систему. Если за этими маршрутами стоят административные интерфейсы или внутренние сервисы, последствия выходят за рамки одного приложения. Ограничивает картину лишь то, что уязвимость проявляется не в любом развёртывании, а только там, где настроена политика externalAuth.
Исправление появилось в версии 5.7.0. Обходных мер вендор не приводит, поэтому обновление остаётся единственным способом закрыть проблему. Вариантов вроде изменения настроек или изоляции узлов в бюллетене нет.
Администраторам нужно сверить версию контроллера в своём кластере со списком уязвимых сборок. Если развёрнута 5.6.0, 5.6.1, 5.6.2 или 5.6.3, перейти на 5.7.0. Проверить, используется ли политика externalAuth, тоже имеет смысл: без неё описанный сценарий не срабатывает. Пока обновление не установлено, риск сохраняется, поскольку других способов его снизить вендор не предложил.
Контроллер входа остаётся местом, где сходятся внешний трафик и внутренние сервисы. Ошибки в проверке прав на этом уровне дают злоумышленнику доступ без аутентификации, который иначе пришлось бы добывать обходными путями. Обновление до 5.7.0 снимает риск, однако требует инвентаризации: ветка 5.x разошлась по разным средам, и версию контроллера отслеживают не везде.
Ссылки
