CVE-2026-71324

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 (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 przed wersjami v2.11.55 i v3.0.0 do v3.7.10 zawiera podatność na konflikt rozwiązywania opcji TLS, która pozwala nieuwierzytelnionym atakującym ominąć uwierzytelnianie certyfikatem klienta poprzez tworzenie sprzecznych opcji TLS na routerach z wieloma hostami. Atakujący mogą dotrzeć do chronionych backendów, wykorzystując wspólne rozwiązywanie TLS dla wielu nazw hostów w jednej regule routera, co powoduje, że ścisły wymóg mTLS jest zastępowany domyślnymi opcjami dla wszystkich hostów.

Traefik w wersjach >= v3.7.0 i <= v3.7.10 zawiera obejście uwierzytelniania w dostawcy Kubernetes Ingress NGINX. Opcja TLS wygenerowana dla Ingress z adnotacją nginx.ingress.kubernetes.io/auth-tls-secret była nazwana według przestrzeni nazw i nazwy Ingress. W rezultacie dwa obiekty Ingress współdzielące ten sam host, ten sam sekret CA klienta i ten sam tryb uwierzytelniania klienta tworzyły dwie różne nazwy opcji TLS dla tego hosta. Traefik traktuje to jako konflikt opcji TLS i wraca do domyślnej konfiguracji TLS punktu wejścia, która nie wymaga certyfikatu klienta, więc trasa skonfigurowana z nginx.ingress.kubernetes.io/auth-tls-verify-client: "on" staje się osiągalna bez certyfikatu klienta. Dotyczy tylko linii v3.7; problem naprawiono w v3.7.11.

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.

Traefik w wersjach od v3.7.1 nie egzekwuje ograniczeń crossProviderNamespaces dla adnotacji traefik.ingress.kubernetes.io/service.middlewares w dostawcy Kubernetes Ingress. Dzierżawca z ograniczeniem do przestrzeni nazw, wykluczony z listy dozwolonych, może dołączyć do swojej usługi middleware należący do operatora, a jeśli ten middleware wstrzykuje poświadczenia backendu, może je odzyskać na kontrolowanym backendzie.

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ę.

Traefik w wersjach przed 3.7.3, 3.6.18 i 2.11.51 ma krytyczną podatność w wyborze konfiguracji TLS dla HTTP/3 (QUIC), która pozwala nieuwierzytelnionym klientom ominąć egzekwowanie mTLS specyficzne dla routera. Gdy HTTP/3 jest włączone na entrypoincie, uzgadnianie TLS wybiera konfigurację TLS na podstawie dokładnego, uwzględniającego wielkość liter wyszukiwania wartości SNI, co nie obsługuje wzorców z wildcardami (np. *.example.com) ani wariantów wielkości liter skonfigurowanej nazwy hosta. W rezultacie klient może ukończyć uzgadnianie QUIC bez przedstawienia certyfikatu, a warstwa routingu HTTP nadal kieruje żądanie do backendu chronionego polityką mTLS specyficzną dla routera.

W Traefik w wersjach od 3.7.0 do 3.7.3 wykryto podatność w mechanizmie ochrony przed domain-fronting (SNICheck). Umożliwia ona nieuwierzytelnionemu klientowi ominięcie wzajemnego uwierzytelniania TLS wymuszonego przez reguły routera z wildcardem, poprzez wysłanie żądania HTTP z nagłówkiem Host do chronionego backendu po wcześniejszym nawiązaniu połączenia TLS z permisjami dla innego SNI.