Traefik версий до 3.7.15 содержит две уязвимости в компоненте, который связывает обратный прокси с объектами Ingress в Kubernetes. Из-за одной из них обязательная проверка клиентского сертификата отключается сама собой, и внутренние сервисы открываются для неаутентифицированных запросов. Вторая нарушает изоляцию пространств имён и позволяет выяснить, существует ли чужой секрет с сертификатом удостоверяющего центра. Исправление вышло 16 октября 2026 года в версии 3.7.15, идентификаторов CVE у обеих проблем пока нет.
Две уязвимости в провайдере Kubernetes Ingress
Traefik - обратный прокси, который часто ставят перед приложениями в кластерах Kubernetes. Его провайдер Kubernetes Ingress NGINX читает настройки, записанные в объектах Ingress, и превращает их в правила маршрутизации и параметры TLS. Обе уязвимости затрагивают именно этот компонент. Traefik второй ветки, где такого провайдера нет, не затронут. Французская служба CERT-FR описывает последствия коротко: нарушение конфиденциальности данных и обход политики безопасности.
Отключение mTLS при конфликте настроек
Уязвимость высокой степени опасности касается взаимной аутентификации по TLS (mTLS), когда сервер проверяет сертификат не только у себя, но и у клиента. Поддержка настройки клиентской аутентификации через аннотацию Ingress появилась в Traefik 3.7.0.
Механизм ошибки прост. Провайдер привязывает параметр клиентской аутентификации к отдельному объекту Ingress, а не ко всему узлу. Если на одном узле один Ingress требует клиентский сертификат, а другой объявляет путь без такой настройки, настройки вступают в конфликт. Traefik возвращается к стандартным параметрам TLS, которые сертификат не запрашивают. Защита снимается молча, предупреждений администратор не получает.
В результате удалённый злоумышленник без учётных данных и без сертификата попадает на внутренние сервисы, доступ к которым должен был требовать проверки. Затронуты версии с 3.7.0, включая 3.7.0-ea.1, по 3.7.14. Выпуски до 3.7.0 и вся вторая ветка Traefik уязвимости не содержат. Автор отчёта об этой проблеме отметил, что готовил его с помощью искусственного интеллекта.
Совместная TLS-опция обходит проверку изоляции
Вторая уязвимость имеет низкую степень опасности и иную природу. Кластеры Kubernetes разделяют объекты по пространствам имён, и Traefik по умолчанию запрещает одному пространству использовать секреты другого. Проверка срабатывает только тогда, когда параметр клиентской аутентификации создаётся впервые.
Обход появляется при повторном использовании. Если секрет с сертификатом удостоверяющего центра уже задействован в другом Ingress, следующий объект получает ту же общую настройку без проверки. Пользователь, которому разрешено создавать Ingress в своём пространстве имён, может применить чужой сертификат удостоверяющего центра к своим маршрутам. Так он обходит настроенную изоляцию. Заодно он узнаёт, существует ли чужой секрет и используется ли он. Содержимое секрета при этом не раскрывается, поэтому ущерб ограничен.
Уязвимость появилась в 3.7.11 вместе с механизмом совместного использования параметров клиентской аутентификации. Затронуты версии с 3.7.11 по 3.7.14, более ранние выпуски такого кода не содержат.
Исправление в версии 3.7.15
Обе проблемы закрывает Traefik 3.7.15, вышедший 16 октября 2026 года. CERT-FR относит к уязвимым все версии до 3.7.15. Отдельных исправлений для ветвей 3.6 и 2.x не требуется, поскольку уязвимый код там отсутствует.
Обновление и обходные меры
Администраторам кластеров, где Traefik работает провайдером Kubernetes Ingress, нужно перейти на 3.7.15. Если обновление отложено, риск отключения mTLS снижает строгий режим TLS-опций (параметр core.strictTLSOptions): в нём конфликт настроек не приводит к подмене стандартными параметрами. Круг пользователей с правом создавать объекты Ingress тоже имеет смысл сузить, ведь именно это право открывает путь ко второй уязвимости.
Обе проблемы касаются не проксирования как такового, а логики связывания настроек TLS с объектами Ingress. Такие ошибки коварны тем, что конфигурация остаётся на месте, а защита перестаёт действовать. Заметить это можно только по косвенным признакам, потому что нужные параметры распределены между множеством объектов кластера, и ни один из них не выглядит подозрительно сам по себе.
Ссылки
- https://github.com/traefik/traefik/security/advisories/GHSA-p8wx-ph99-xgcr
- https://github.com/traefik/traefik/security/advisories/GHSA-28hp-c82p-8vqj
