CVE-2026-88004

Traefik to otwartoźródłowy odwrotny serwer proxy i load balancer. Od wersji 2.8.2 do 2.11.56 oraz 3.7.12 punkty wejściowe HTTP/3 nie stosują entryPoints..transport.respondingTimeouts.readTimeout, ponieważ limit czasu jest wymuszany na połączeniu TCP, a serwer HTTP/3 nie ma odpowiadającego terminu strumienia QUIC. Nieuwierzytelniony klient może użyć powolnego ciała żądania, sącząc dane w nieskończoność, trzymając żądanie i połączenie nadrzędne otwarte oraz wyczerpując backendy o ograniczonych pulach połączeń. Problem naprawiono w wersjach 2.11.56 i 3.7.12.

Traefik to otwartoźródłowy odwrotny serwer proxy i load balancer. W wersjach przed 2.11.56 oraz od 3.0.0 do 3.7.12 nagłówek w formie z kropkami dostarczony przez klienta, taki jak X.Authenticated.User, przechodzi przez zastąpienie ForwardAuth i underscoreHeadersStrategy, ponieważ Go traktuje go jako odrębny od X-Authenticated-User, podczas gdy backendy CGI, WSGI, PHP i NGINX podatne na normalizację łączą obie nazwy. Backend może w konsekwencji użyć wartości klienta zamiast tożsamości potwierdzonej przez Traefik, umożliwiając podszywanie się pod tożsamość dla dowolnego nagłówka zarządzanego przez Traefik. Ochrona aliasHeadersStrategy jest domyślnie wyłączona i musi być skonfigurowana jako delete lub reject. Środek zaradczy jest dostępny w wersjach 2.11.56 i 3.7.12.

W Traefik przed wersjami 2.11.57 i 3.7.13 akceptowany jest bezrootowy cel żądania HTTP/1, który Go przechowuje w URL.Opaque, pozostawiając URL.Path pusty. Ścieżka rewriteRequestBuilder ocenia routing, sanityzację ścieżki, forwardAuth, encodedCharacters i logowanie dostępu na podstawie ścieżki znormalizowanej do /, ale przekazuje URL.Opaque dosłownie do backendu, co pozwala na obejście routingu między wirtualnymi hostami, obejście autoryzacji opartej na ścieżce i unikanie logów dostępu.

W Traefik od wersji 2.11.26 do 2.11.57 i 3.7.13, Traefik przekazuje do współdzielonego backendu nagłówek Connection żądający Upgrade, token Upgrade: h2c oraz HTTP2-Settings. Jeśli backend zaakceptuje h2c i zwróci 101 Switching Protocols, Traefik wchodzi w tryb surowego tunelu i przestaje stosować routery, BasicAuth, ForwardAuth, IPAllowList, RateLimit, logowanie dostępu, metryki i śledzenie do późniejszych żądań HTTP/2, co pozwala nieuwierzytelnionemu żądaniu przejść przez niechronioną trasę do chronionych ścieżek w tym samym backendzie.

Traefik w wersjach v1.x, v2.x do v2.11.55 oraz v3.0.0 do v3.7.11 kanonikalizuje nazwy nagłówków tylko po myślnikach, przez co X-Auth-User, X_Auth_User i X.Auth.User są traktowane jako trzy różne nagłówki, podczas gdy backendy (CGI, WSGI, PHP, NGINX i inne) sprowadzają je do jednej zmiennej. Klient może przemycić alias z kropką nagłówka zarządzanego przez Traefik obok kanonicznej wersji, np. X.Authenticated.User obok X-Authenticated-User, powodując, że backend odczyta wartość dostarczoną przez klienta zamiast tożsamości potwierdzonej przez Traefik.

Traefik w wersjach od v2.8.2 do v2.11.55 oraz od v3.0.0 do v3.7.11 nie stosuje ustawień entryPoints.<name>.transport.respondingTimeouts (w szczególności readTimeout, domyślnie 60s) do ścieżki żądań HTTP/3. readTimeout jest egzekwowany jako deadline na połączeniu TCP, czego nie można zastosować do strumienia QUIC, a serwer HTTP/3 w Traefik jest tworzony bez żadnego timeoutu. W efekcie nieuwierzytelniony zdalny klient może przesyłać bajty ciała żądania powoli i utrzymywać żądanie otwarte bezterminowo.

Traefik (open source HTTP reverse proxy i load balancer) w wersjach od 2.11.0 do 2.11.57 oraz 3.7.13 ma błąd w obsłudze HTTP/3: ConnContext nie wywołuje service.AddTransportOnContext, przez co kerberosRoundTripper używa współdzielonego transportu backendu zamiast dedykowanego dla każdego połączenia frontendu. Przy włączonym HTTP/3, backendzie używającym uwierzytelniania NTLM lub Negotiate związanego z połączeniem oraz keep-alive, niepowiązany klient może ponownie użyć połączenia backendu uwierzytelnionego dla ofiary, odczytać dane ofiary i działać jako ofiara bez jej poświadczeń.

Traefik (HTTP reverse proxy i load balancer) w wersjach >= v3.7.0 i <= v3.7.11 ma błąd w providerze Kubernetes ingress-nginx dotyczący Ingressów z jednocześnie ustawioną adnotacją uwierzytelniania i adnotacją nginx.ingress.kubernetes.io/from-to-www-redirect. Provider tworzy dodatkowy router 'sibling', który dopasowuje tylko host, zawiera wyłącznie middleware RedirectRegex i wskazuje na chroniony backend routera nadrzędnego. Ponieważ RedirectRegex nie jest terminalnym handlerem, żądanie niedopasowane do wzorca jest przekazywane do backendu, a ponieważ wzorzec przekierowania akceptuje tylko port numeryczny, żądanie z portem nienumerycznym lub pustym (np. 'Host: www.example.com:x') wybiera router sibling, omija przekierowanie i jest proxowane do chronionego backendu bez żadnych middleware'ów wynikających z adnotacji Ingress. Powoduje to utratę nie tylko uwierzytelniania (np. BasicAuth), ale także wszystkich middleware'ów z adnotacji, w tym allowlisty źródłowych adresów IP. Wersje Traefik v2 i v3 przed v3.7.0 nie są podatne. Problem naprawiono w v3.7.12.

Traefik w wersjach przed v2.11.55 oraz w wersjach v3.0.0 do v3.7.10 zawiera podatność na obejście uwierzytelniania w middleware digestAuth, gdzie nieznane nazwy użytkowników otrzymują pusty sekret zamiast odrzucenia. Atakujący mogą obliczyć poprawną odpowiedź digest przy użyciu pustego sekretu i dowolnych poświadczeń, aby obejść uwierzytelnianie na dowolnej trasie chronionej przez digestAuth bez ważnej nazwy użytkownika lub hasła.

W Traefik przed wersjami v2.11.51, v3.6.22 i v3.7.6, mechanizmy uwierzytelniania BasicAuth, DigestAuth i ForwardAuth nie usuwają nagłówków tożsamości z podkreślnikami, które backendy normalizują do postaci z myślnikami. Atakujący może wstrzyknąć taki nagłówek, aby podszyć się pod tożsamość lub ominąć autoryzację.