The post has been translated automatically. Original language: Russian
On September 4, 2026, the Traefik project released two versions of the reverse proxy at once — 3.7.13 for the current branch and 2.11.57 for the support branch. Along with them, five security notices were published, one of which received a critical rating of 9.1 on CVSS. All the defects are about parsing the incoming request and choosing a connection to the backend.
Backend connection acquired by someone else's client
The most difficult problem lives at the HTTP/3 entry point. It reuses the HTTPS handler chain, but skips the step that sets up transport isolation at the connection level — for HTTP/1.1 and HTTP/2, it is performed normally. As a result, separate authentication holders are not created for each client connection.
The effect is manifested when three conditions are combined: HTTP/3 is enabled, the backend uses NTLM or Negotiate (Kerberos) authentication tied to the connection, and connection reuse is not disabled. Then an unauthenticated client can get into someone else's already authenticated connection, read another user's data and perform an action on his behalf. Per-request authentication schemes are not affected. Versions from 3.0.0 to 3.7.12 and from 2.11.0 to 2.11.56 are vulnerable.
The target of the request that does not match the route
The second defect (score 8.8) is related to the parsing of HTTP/1.x requests, where the target is specified in an opaque form, rather than the usual way. The standard URL parser in Go puts such a string in the Opaque field, leaving the path empty. Traefik routes along the normalized path "/", and sends the source string verbatim to the backend.
The discrepancy has three consequences: the request goes to the wrong virtual host; forwardAuth checks linked to the path are triggered for the wrong purpose; the request looks normal in the access log. The documented prohibition of the encoded slash does not help here.
Trailers, h2c tunnel, and BasicAuth timing
The three remaining notifications are easier to evaluate. Sanitization of header names at the entry point only looks at headers and does not look at trailers: the name that the reject mode should reject with the 400 code, and the delete mode should delete, calmly passes in HTTP/1.1 trailers with chunks or HTTP/2. The X-Forwarded family headers are also not cleaned from untrusted clients. Versions 3.2.0 to 3.7.12 are affected; the second branch is not affected.
The next problem is the Upgrade header with the h2c value, which the proxy passed to the backend without restrictions. If the backend responds with code 101, Traefik switches to raw byte tunneling mode, and further requests go past routing and middleware: past BasicAuth and ForwardAuth, lists of allowed addresses, frequency limiter, logs, metrics, and tracing.
Finally, middleware BasicAuth combined simultaneous password checks with the singlelight mechanism, but built a pooling key involving a stored secret. Non—existent names were compressed into a common key and serviced quickly, and for existing ones, the hash was calculated anew - the difference in response time allowed the accounts to be listed. There is no password disclosure or password-free login here.
What does this mean in practice?
The first is to find out if HTTP is enabled on the entry points./3. If not, the most severe of the five defects does not concern you. If so, and there are domain-authenticated services behind the proxy, you need to upgrade out of turn.
The second is to look at the router map: it is not the h2c header itself that is dangerous, but the situation when one backend is serviced by both a secure and an open router.
The third thing is not to rely on logs when analyzing an incident: in a scenario with an opaque purpose, an entry in the access log looks normal, and traces will have to be searched on the backend.
And fourth, there are not only security edits in the release: recursive DNS record propagation verification is disabled by default for ACME, and a separate transport per client connection is set up for HTTP/3. The default behavior is changing, so it's worth following the migration guide.
The draft text was prepared with the participation of AI, the facts were checked against the original source — official release notes and security notices of the Traefik project.
Проект Traefik выпустил 4 сентября 2026 года сразу две версии обратного прокси — 3.7.13 для актуальной ветки и 2.11.57 для ветки поддержки. Вместе с ними опубликованы пять уведомлений безопасности, одно из которых получило критическую оценку 9.1 по CVSS. Все дефекты — про разбор входящего запроса и выбор соединения к бэкенду.
Соединение к бэкенду, доставшееся чужому клиенту
Самая тяжёлая проблема живёт в точке входа HTTP/3. Она переиспользует цепочку обработчиков HTTPS, но пропускает шаг, который заводит изоляцию транспорта на уровне соединения — для HTTP/1.1 и HTTP/2 он выполняется штатно. В итоге не создаются отдельные держатели аутентификации на каждое клиентское соединение.
Эффект проявляется при сочетании трёх условий: включён HTTP/3, бэкенд использует привязанную к соединению аутентификацию NTLM или Negotiate (Kerberos), переиспользование соединений не отключено. Тогда неаутентифицированный клиент может попасть в уже аутентифицированное чужое соединение, прочитать данные другого пользователя и выполнить действие от его имени. Схемы с аутентификацией на каждый запрос не затронуты. Уязвимы версии от 3.0.0 до 3.7.12 и от 2.11.0 до 2.11.56.
Цель запроса, которая не совпадает с маршрутом
Второй дефект (оценка 8.8) связан с разбором запросов HTTP/1.x, где цель указана в непрозрачной форме, а не обычным путём. Стандартный разборщик URL в Go кладёт такую строку в поле Opaque, оставляя путь пустым. Traefik маршрутизирует по нормализованному пути «/», а на бэкенд отправляет исходную строку дословно.
Расхождение даёт три следствия: запрос уходит не на тот виртуальный хост; проверки forwardAuth, привязанные к пути, срабатывают не на ту цель; в журнале доступа запрос выглядит обычным. Документированный запрет кодированного слэша здесь не помогает.
Трейлеры, туннель h2c и тайминг BasicAuth
Три оставшихся уведомления легче по оценке. Санитизация имён заголовков на точке входа смотрит только заголовки и не смотрит трейлеры: имя, которое режим reject должен отклонить кодом 400, а режим delete — удалить, спокойно проезжает в трейлерах HTTP/1.1 с чанками или HTTP/2. Так же не вычищаются заголовки семейства X-Forwarded от недоверенных клиентов. Затронуты версии от 3.2.0 до 3.7.12; вторая ветка не задета.
Следующая проблема — заголовок Upgrade со значением h2c, который прокси передавал бэкенду без ограничений. Если бэкенд отвечает кодом 101, Traefik переходит в режим сырого туннелирования байтов, и дальнейшие запросы идут мимо маршрутизации и middleware: мимо BasicAuth и ForwardAuth, списков разрешённых адресов, ограничителя частоты, логов, метрик и трассировки.
Наконец, middleware BasicAuth объединял одновременные проверки пароля механизмом singleflight, но строил ключ объединения с участием хранимого секрета. Несуществующие имена схлопывались в общий ключ и обслуживались быстро, а для существующих хеш считался заново — разница во времени ответа позволяла перечислять учётные записи. Раскрытия паролей и входа без пароля здесь нет.
Что это значит на практике
Первое — выяснить, включён ли на точках входа HTTP/3. Если нет, самый тяжёлый из пяти дефектов вас не касается. Если да, а за прокси стоят сервисы с доменной аутентификацией, обновляться нужно вне очереди.
Второе — посмотреть на карту роутеров: опасен не сам заголовок h2c, а ситуация, когда один бэкенд обслуживается и защищённым, и открытым роутером.
Третье — не рассчитывать на журналы при разборе инцидента: в сценарии с непрозрачной целью запись в журнале доступа выглядит обычно, следы придётся искать на бэкенде.
И четвёртое — в выпуске есть не только правки безопасности: для ACME по умолчанию отключена рекурсивная проверка распространения DNS-записей, для HTTP/3 заведён отдельный транспорт на клиентское соединение. Поведение по умолчанию меняется, так что стоит пройтись по руководству по миграции.
Черновик текста подготовлен с участием ИИ, факты сверены с первоисточником — официальные заметки к выпуску и уведомления безопасности проекта Traefik.
Share
