Уязвимость в промежуточном ПО ForwardAuth обратного прокси Traefik позволяет клиенту без учётных данных получить доступ к защищённому бэкенду под идентичностью другого пользователя. Оценка High по CVSS v4.0. Затронуты ветки Traefik 2.x до 2.11.59 включительно и 3.x от 3.0.0 до 3.7.15 включительно. Идентификатор CVE не присвоен, бюллетень GHSA-hrpp-p4fc-wwf8 опубликован 21 октября 2026 года.
Подмена идентичности при NTLM и Negotiate через ForwardAuth
ForwardAuth - механизм Traefik, который передаёт проверку подлинности внешнему серверу аутентификации. Обратный прокси отправляет ему подзапрос по каждому входящему запросу клиента. При успешной проверке Traefik переносит заголовки ответа сервера аутентификации на бэкенд (защищаемое приложение), и приложение считает запрос принадлежащим опознанному пользователю. Схема распространена в развёртываниях Traefik перед внутренними сервисами, где вход выполняет корпоративный портал или домен Active Directory.
Схемы NTLM и SPNEGO/Kerberos с согласованием параметров (Negotiate) привязывают сессию к конкретному сетевому подключению. Сервер считает клиента опознанным, пока соединение открыто, и повторную проверку в его рамках не выполняет. Traefik же отправляет подзапросы ForwardAuth через пул, то есть набор переиспользуемых соединений, общий для всех клиентов этого промежуточного ПО. Поэтому подключение, уже подтверждённое от имени одного пользователя, может быть переиспользовано для подзапроса постороннего клиента.
В результате клиент без учётных данных получает успешный ответ аутентификации с идентичностью жертвы, а Traefik передаёт её защищаемому приложению. В версии 3.7 то же поведение распространяется на внешние запросы аутентификации для аннотации auth-url провайдера Kubernetes Ingress NGINX. Уязвимость различается с четырьмя предыдущими бюллетенями, включая GHSA-53qr-784g-cj35: те закрывали привязанную к подключению аутентификацию только на путях обратного проксирования.
Исправление вышло в Traefik 2.11.60 и 3.7.16. Оно добавляет изоляцию подключений к серверу аутентификации по каждому клиентскому подключению. Ветки 3.0-3.6 сняты с поддержки, отдельного исправления для них не будет, пользователям нужен переход на 2.11.60 или 3.7.16. Ветка 2.x по-прежнему получает патчи, поэтому номер 2.11.60 меньше, чем 3.7.15, хотя исправление для линии 3.x выпущено под номером 3.7.16.
Эксплуатация требует сервера аутентификации со схемой, привязанной к подключению; типичный пример - IIS Windows Authentication с NTLM или Negotiate. Нужно также, чтобы через тот же экземпляр Traefik уже проходил проверку хотя бы один пользователь. Взаимодействие с жертвой не требуется, учётные данные атакующему не нужны, атака идёт по сети. Сведений об эксплуатации в реальных атаках и публичного эксплойта в бюллетене нет.
Администраторам нужно обновить Traefik до 2.11.60 на ветке 2.x или до 3.7.16 на ветке 3.x. Для развёртываний на 3.0-3.6 поддерживаемой версии нет, поэтому требуется переход на одну из двух исправленных линий. Пока обновление не установлено, отключите ForwardAuth на подключениях с доступом из недоверенных сетей либо переведите сервер аутентификации на схему без привязки к подключению, например на проверку токена или Basic. Проверьте манифесты Kubernetes на аннотацию auth-url: она включает тот же путь аутентификации в версии 3.7.
Проблема затрагивает только конфигурации с аутентификацией, привязанной к подключению. В таких развёртываниях разграничение доступа между пользователями теряется полностью, поскольку любой внешний клиент может получить права того, кто прошёл проверку раньше. Значения SC:H и SI:H в векторе отражают высокое влияние на конфиденциальность и целостность последующих систем.
Ссылки
