Traefik 3.7.14 и 2.11.58 закрывают восемь уязвимостей, включая доступ к чужой аутентифицированной сессии

Семь из восьми уязвимостей, описанных в бюллетенях Traefik от 7 октября 2026 года, получили уровень High по классификации проекта, ещё одна - Moderate. Идентификаторы CVE ни одной из них пока не присвоены. Затронуты обе поддерживаемые ветки: выпуски 3.x до v3.7.14 и версии до v2.11.58. Traefik служит обратным прокси и балансировщиком нагрузки, его ставят на входе в инфраструктуру, часто в Kubernetes. Потому ошибки в логике аутентификации между клиентом и внутренними сервисами затрагивают всё, что стоит за прокси.

Детали уязвимостей

Четыре уязвимости связаны с привязкой удостоверения к сетевому соединению. Так устроены механизмы NTLM и Negotiate (Kerberos): внутренний сервис считает клиента аутентифицированным только до тех пор, пока тот обращается по тому же соединению. Traefik поддерживал этот режим, сохраняя отдельный транспорт для каждого клиентского подключения. Ошибки в такой логике и открывают чужую сессию.

В первом случае клиент присылает готовый токен Negotiate в самом первом запросе, минуя обычный обмен с ответом 401. Внутренний сервис аутентифицирует соединение из общего пула, и этот сокет остаётся в пуле. Посторонний клиент с отдельным подключением может получить тот же сокет и действовать с правами жертвы. Обычный сценарий с предварительным запросом не затронут: выделенный транспорт создаётся до отправки учётных данных. Уязвимость появилась вместе с поддержкой NTLM и Kerberos в v2.11.0 и v3.0.0.

Во втором случае выделенный транспорт хранил всю конфигурацию, включая параметры TLS. Ячейка, где он лежал, была общей для всех описаний серверных транспортов. После первого запроса к одному сервису она переиспользовалась для последующих запросов, в том числе к другому сервису. В результате соединение ко второму сервису устанавливалось с настройками TLS от первого: чужие корневые сертификаты, чужое имя сервера, чужой клиентский сертификат. Оператор терял контроль над политикой TLS на этом участке.

Третья уязвимость той же группы связана с конкурентным доступом. Протоколы HTTP/2 и HTTP/3 передают несколько запросов по одному соединению, а ячейку с транспортом читали и перезаписывали без синхронизации. Гонка могла затереть уже используемый транспорт или привести к аварийному завершению процесса Traefik. Эту проблему оценили как Moderate.

Четвёртая касается экспериментального режима FastProxy, появившегося в v3.2. В нём запросы к обычным http-бэкендам идут через собственный пул соединений, где изоляция по клиенту не применялась. Неаутентифицированный клиент с новым подключением мог получить соединение, на котором другой пользователь уже прошёл проверку NTLM или Negotiate. После этого он читал чужие данные либо действовал за жертву. Для атаки нужны включённый FastProxy, обычный HTTP-бэкенд с аутентификацией NTLM или Negotiate и поддержание соединения на стороне сервиса. Обычная реализация прокси не затронута, а ветки 3.2-3.6 больше не получают патчей.

Ещё три уязвимости затрагивают работу Traefik с Kubernetes через провайдер Ingress-NGINX, и все они относятся только к ветке v3.7. В одном случае промежуточный обработчик, отвечающий за заголовки с данными клиентского сертификата, привязывался лишь к TLS-маршруту. Параллельный HTTP-маршрут передавал такие заголовки бэкенду как есть. Если перенаправление на HTTPS отключено, неаутентифицированный клиент подставляет заголовок об успешной проверке сертификата вместе с произвольными данными о нём. Внутренний сервис, доверяющий этим полям, пропускает запрос без предъявления сертификата.

Вторая проблема касается режима ssl-passthrough. Начиная с v3.7.13, Ingress с этой пометкой получает дополнительный HTTP-маршрут на портах без TLS. Его строили в обход общей обработки, поэтому объявленные в том же Ingress правила контроля доступа не превращались в фильтры. Клиент без аутентификации по имени узла попадал на защищённый по замыслу бэкенд, без проверки учётных данных, без ограничения по адресам источника и без записи в журнале.

Третья связана с именами TLS-опций. Имя опции строилось из пространства имён и имени секрета, при этом точки заменялись на дефисы. Два секрета, чьи имена отличаются точкой и дефисом, давали одинаковое имя опции, и второй Ingress молча использовал опцию первого. В результате один узел начинал принимать сертификаты, выпущенные чужим центром сертификации, а законные клиенты этого узла получали отказ.

Восьмая уязвимость затрагивает проверку SNI (Server Name Indication, указание имени сервера при установке TLS-соединения). Traefik должен пропускать запрос по TLS-соединению только к тому маршруту, чьи параметры TLS совпадают с согласованными для этого соединения. Проверка не выполнялась, когда у запроса отсутствовало состояние TLS. В сборках Traefik на Go 1.27 такое состояние не заполняется для запросов HTTP/2 с признаком http по TLS-соединению. Клиент мог попасть на маршрут с другими параметрами, например требующий клиентский сертификат, не предъявляя его. Официальные сборки и образы Traefik собраны на Go 1.26 и не подвержены проблеме, а сторонние пересборки на Go 1.27 уязвимы.

Исправления вошли в v3.7.14 и v2.11.58. Ветки 3.0-3.6 больше не поддерживаются и патчей не получат, их пользователям нужно перейти на v3.7.14. Обходных путей разработчики не приводят, помогает только переход на новые выпуски.

Общая черта большинства этих уязвимостей - доверие к состоянию соединения. Когда удостоверение клиента привязывают к сетевому сокету, от изоляции пула соединений зависит вся защита. Малейшая ошибка в ключе пула или в синхронизации доступа открывает чужую сессию. Тем, кто использует за Traefik аутентификацию NTLM или Kerberos, обновиться нужно сразу, а заодно проверить настройки TLS и экспериментальные режимы вроде FastProxy.

Детали уязвимостей

Ссылки