В Traefik нашли уязвимость, из-за которой клиент без учётных данных может исчерпать ресурсы процесса. Достаточно открыть много коротких соединений с заголовком авторизации и схемой NTLM или Negotiate. В результате сервер теряет память и дескрипторы. Затронуты обе поддерживаемые ветки прокси, а обычный внешний трафик на входе становится средством отказа.
Утечка транспорта бэкенда в Traefik GHSA-xv5x-242w-7hf7
Проблема появилась вместе с поддержкой NTLM и Kerberos в Traefik. С версий 2.11.58 и 3.7.14 прокси выделяет отдельный транспорт на каждое клиентское соединение. При этом прежние выпуски создавали транспорт только после ответа бэкенда с запросом NTLM или Negotiate. Поэтому ветки 3.6 и ниже, а также 2.11.57 и ниже уязвимость не затрагивает. Всё решает одна версия.
Транспорт - это набор соединений к бэкенду, который Traefik держит под каждого клиента. Создаётся он сразу, как только в запросе появляется заголовок авторизации со схемой NTLM или Negotiate. Ни пароля, ни ответа бэкенда для этого не нужно. После закрытия клиентского соединения транспорт остаётся в памяти. Простаивающее соединение с бэкендом и горутины, лёгкие потоки Go, тоже не освобождаются.
В штатной схеме NTLM и Kerberos работают иначе. Бэкенд сам просит аутентификацию ответом с запросом NTLM или Negotiate. Только после такого ответа прокси выделяет отдельный транспорт. В уязвимых версиях этот шаг пропущен, и транспорт появляется сразу. Поэтому проверка на стороне бэкенда не успевает вмешаться, и утечка начинается раньше.
Память занимают и сами горутины, пока их не освободят. На стороне бэкенда каждый остаток держит слот соединения. При этом клиент может закрывать соединения сразу. Чем больше коротких соединений, тем больше остатков. Та же схема есть в FastProxy, поэтому смена реализации не помогает.
Условия атаки и оценка вендора
Атака идёт по сети, снаружи, без доступа к хосту: учётные данные не нужны, участие пользователя тоже. Барьеров у атакующего нет, сложность низкая. Уязвимость получила высокую важность в бюллетене GHSA-xv5x-242w-7hf7 от 02 ноября 2026 года. Затронута только доступность, целостность и конфиденциальность не страдают. При этом утечка идёт и там, где бэкенды с NTLM или Kerberos не настроены вовсе.
Для организации это значит, что отказ на входе затрагивает все сервисы за прокси, а не только сам Traefik. Клиенту это почти ничего не стоит. Зато сервер тратит на него память, файловые дескрипторы и свободные соединения с бэкендом. Из-за этого процесс может перестать принимать новый трафик, а восстановление обычно требует перезапуска. Чем дольше идёт поток запросов, тем быстрее кончаются ресурсы.
Вендор выпустил исправления. Ветку 2.x закрывает Traefik 2.11.61, а ветку 3.x закрывает 3.7.17. Обновление действует и в основном прокси, и в FastProxy. При этом сведений об эксплуатации уязвимости в реальных атаках в бюллетене нет. Идентификатор CVE не присвоен, обходных мер источник не приводит, а среди слабостей указаны CWE-400 и CWE-772.
Бюллетень GHSA-xv5x-242w-7hf7 опубликовал kevinpollet. В отчёте прямо сказано, что его подготовили с помощью ИИ. Для администратора это ничего не меняет: проверять нужно версию, а не происхождение отчёта. Главный признак риска - сборка из уязвимого диапазона версий. Поэтому проверку можно провести за минуту и без доступа к внутренним сетям.
Что делать администраторам
Проверять нужно в первую очередь узлы, которые принимают внешние запросы из интернета. Уязвимость затрагивает Go-модули обеих веток. Обновиться нужно и там, где единый вход в бэкенды не используется. После обновления нужна версия 2.11.61 или 3.7.17. До перезапуска старые транспорты держат память и дескрипторы процесса.
Ссылки
