Уязвимости в Traefik нарушают изоляцию namespace и позволяют подменять личность

В Traefik - популярном обратном прокси для Kubernetes - обнаружили три уязвимости, связанные с обработкой ресурсов кластера. Они позволяют обходить политику безопасности и нарушать изоляцию между пространствами имён (namespace). В отдельных случаях атакующий может подменить результат аутентификации. Разработчики уже выпустили исправления для всех затронутых веток.

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

Traefik широко используется как единая точка входа в микросервисные приложения. Кроме того, он автоматически получает конфигурацию из API Kubernetes, поэтому ошибки в этой интеграции затрагивают большое число развёртываний. В частности, проблемы обнаружились в трёх компонентах: провайдере пользовательских ресурсов Kubernetes (CRD), механизме базовой аутентификации и провайдере Gateway API - интерфейсе для настройки маршрутизации. Разработчики опубликовали информацию о них в трёх бюллетенях GitHub Security Advisories от 3 августа 2026 года.

Первая уязвимость относится к средней степени опасности. Она связана с сущностями TraefikService, которые описывают бэкенды для маршрутизации. Между тем, в настройках прокси существует параметр allowCrossNamespace, который по умолчанию запрещает ссылки на объекты из других пространств имён. Разработчики применяли это ограничение к промежуточному ПО, TLS-опциям и транспортам, однако пропустили TraefikService. В результате пользователь с правами только внутри своего namespace может привязать свой роутер к сервису из соседнего пространства имён. Это открывает доступ к внутренним бэкендам и позволяет перенаправлять их трафик через собственный роутер. Для эксплуатации достаточно возможности создавать или изменять ресурсы в своём пространстве имён и указать ссылку на чужой TraefikService.

Вторая уязвимость имеет низкий уровень угрозы. Она возникает в механизме базовой аутентификации. В свою очередь, когда несколько запросов проверяются одновременно, Traefik объединяет их через механизм singleflight - способ избежать повторных вычислений. Ключ такого объединения формировался из пароля и секрета без разделителя. Из-за этого запрос с несуществующим пользователем, у которого секрет пуст, может совпасть по ключу с легитимным запросом и получить его успешный ответ. При этом для эксплуатации нужны уже полученные учётные данные и доступ к хэшам паролей. Такие возможности есть только у администраторов или при компрометации внутренних сервисов, поэтому практический риск ограничен.

Самая серьёзная уязвимость - высокой степени опасности - найдена в провайдере Gateway API. Этот интерфейс используется для настройки маршрутизации через HTTPRoute, GRPCRoute, TCPRoute и TLSRoute. Идентификатор каждого маршрута формируется склейкой нескольких полей: пространства имён, имени маршрута, идентификатора шлюза, точки входа и индекса правила. Разделителем служит дефис, однако Kubernetes позволяет использовать дефисы внутри имён. Поэтому разные маршруты могут получить одинаковый идентификатор. В таком случае маршрут, загруженный позже, молча перезаписывает предыдущий. Пользователь, создавший такой конфликт, может перенаправить трафик чужого namespace на свой бэкенд. Это ведёт к перехвату данных или нарушению работы соседних сервисов. Для атаки требуется возможность создать маршрут, который будет принят Gateway API. Остальные условия - низкие привилегии и сетевой доступ к прокси.

Уязвимости затрагивают несколько веток Traefik. Например, для первой проблемы опасны версии до 2.11.53 включительно, а также все версии 3.6 до 3.6.24 и 3.7 до 3.7.9. Вторая уязвимость присутствует только в версиях 3.6.11 и новее вплоть до 3.6.24, а также в ветке 3.7 до 3.7.9. Третья затрагивает все версии 3.x до 3.6.24 и 3.7.0-3.7.9. Разработчики включили исправления в релизы v2.11.54, v3.6.25 и v3.7.10.

Между тем, ветки 3.x ниже 3.6 разработчики больше не поддерживают. Отдельных патчей для них не существует, поэтому пользователям следует перейти на актуальную ветку. Вторая уязвимость не затрагивает версии 2.x и ранние версии 3.x, но для них актуальны другие проблемы, устраняемые теми же обновлениями.

Подобные ошибки особенно опасны в мультитенантных средах, где в одном кластере Kubernetes работают несколько команд или даже разных организаций. Такое нарушение изоляции между пространствами имён может привести к утечке данных, несанкционированному доступу к внутренним сервисам и компрометации всей системы. Хотя для эксплуатации второй уязвимости требуются высокие привилегии, рядовой пользователь с минимальными правами может использовать коллизии в Gateway API. Это делает третью уязвимость наиболее приоритетной для закрытия.

Разработчики Traefik рекомендуют обновить прокси до версий v2.11.54, v3.6.25 или v3.7.10. Администраторам также стоит проверить, какие сущности Kubernetes доступны пользователям, ограничить доступ к API и секретам, а также убедиться, что в кластере не созданы конфликтующие маршруты. До установки обновлений можно временно отключить использование Gateway API или CRD-провайдера, если это позволяют бизнес-требования.

Уязвимости в Traefik привлекли внимание к проблеме корректного формирования идентификаторов в системах маршрутизации. Ошибки в построении уникальных ключей могут незаметно разрушить изоляцию между арендаторами кластера. Разработчики уже изменили алгоритмы формирования ключей для singleflight и идентификаторов маршрутов, чтобы исключить коллизии. Пользователям рекомендуется как можно скорее установить обновления, поскольку эксплуатация некоторых из этих уязвимостей не требует сложных условий.

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

Ссылки