Podatności Traefik

Traefik od wersji 3.7.0-ea.1 przed 3.7.15 zawiera podatność obejścia uwierzytelniania w providerze Kubernetes Ingress NGINX, która po cichu wyłącza mTLS skonfigurowany przez adnotację auth-tls-secret. Gdy inny Ingress deklaruje ścieżkę na tym samym hoście bez pasujących ustawień auth-tls, Traefik używa domyślnych opcji TLS.

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.

Podatność w Traefik (przed 2.11.53, 3.6.24 i 3.7.9) w domyślnym proxy HTTP. Przekazywanie żądań CONNECT może prowadzić do desynchronizacji połączeń, umożliwiając atakującemu przemycenie odpowiedzi do innego klienta.

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.

W Traefik przed wersjami 2.11.48, 3.6.19 i 3.7.3 wykryto podatność w middleware StripPrefix. Nieuwierzytelniony atakujący może ominąć uwierzytelnianie i autoryzację na poziomie routingu, używając ścieżek zawierających .. lub %2e%2e, które po normalizacji prowadzą do chronionych zasobów.

Podatność w Traefiku pozwala użytkownikowi z uprawnieniami do tworzenia tras HTTP w Kubernetes Gateway API na ominięcie ustawienia providers.rest.insecure=false i uzyskanie dostępu do REST provider handler. Dzięki akceptowaniu backendów TraefikService z nazwą kończącą się na @internal, możliwe jest przekierowanie ruchu do rest@internal, co w środowiskach współdzielonych umożliwia nieautoryzowaną zmianę konfiguracji routerów i usług.

W Traefik wykryto podatność na ominięcie uwierzytelniania w mechanizmie ForwardAuth i middleware opartym na snippetach. Problem wynika z braku normalizacji nagłówków zawierających podkreślniki zamiast myślników, co pozwala atakującemu na wstrzyknięcie spreparowanych nagłówków i ominięcie uwierzytelniania bez ważnych poświadczeń.

W Traefik wykryto podatność na ominięcie uwierzytelniania w middleware ForwardAuth, gdy opcja trustForwardHeader=false jest skonfigurowana, a Traefik działa za zaufanym proxy upstream. Problem został załatany w wersjach 2.11.43, 3.6.14 i 3.7.0-rc.2.

Traefik od wersji 3.2.0 przed 3.7.15 zawiera wyścig danych w eksperymentalnym FastProxy, który pozwala nieuwierzytelnionym atakującym zawiesić proces poprzez nadużycie aktualizacji protokołu HTTP/1. Atakujący może wielokrotnie otwierać i przerywać zaktualizowane połączenia, takie jak WebSocket, uszkadzając niezsynchronizowany współdzielony bufio.Reader i wywołując nieodzyskany panic, który kończy działanie Traefika.

Traefik w wersji 3.7.11 przed 3.7.15 zawiera obejście autoryzacji w providerze Kubernetes Ingress NGINX, które pomija sprawdzenie między przestrzeniami nazw dla adnotacji auth-tls-secret, gdy ponownie używana jest buforowana opcja TLS uwierzytelniania klienta. Użytkownicy mogący tworzyć Ingressy mogą odwołać się do sekretu CA innej przestrzeni nazw już używanego przez inny Ingress, wymuszając go na własnych trasach i dowiadując się, czy istnieje, bez ujawnienia jego zawartości.

Traefik przed wersją 2.11.58 i 3.7.13 zawiera podatność obejścia uwierzytelniania, która pozwala nieuwierzytelnionym klientom pominąć sprawdzanie certyfikatów klienta, ponieważ zanegowane matchery Host są liczone jako obsługiwane domeny. Atakujący może dotrzeć do backendów chronionych przez RequireAndVerifyClientCert, gdy reguła routera z !Host() tworzy konflikt opcji TLS, który powoduje powrót do opcji domyślnych.

Traefik w wersjach 2.11.0 przed 2.11.58 oraz 3.0.0 przed 3.7.14 przechowuje swój backendowy round tripper NTLM/Kerberos w slocie połączenia klienta, który nie jest kluczowany przez ServersTransport, więc konfiguracja klienta TLS jednej usługi jest ponownie używana dla backendu innej usługi. Nieuwierzytelniony klient może uzbroić slot poprzez backend wysyłający wyzwanie NTLM lub Negotiate, a następnie dotrzeć do innej usługi na tym samym połączeniu keep-alive, omijając jej główne CA, nazwę serwera i weryfikację certyfikatu.

Traefik w wersjach 2.11.x przed 2.11.58 oraz 3.x przed 3.7.14 zawiera warunek wyścigu w uwierzytelnianiu backendu NTLM i Kerberos (Negotiate), gdzie slot sticky round tripper dla połączenia jest odczytywany i zapisywany bez synchronizacji. Zdalni atakujący mogą wysyłać równoległe żądania HTTP/2 lub HTTP/3 przez jedno połączenie, aby osierocić połączenia backendu, złamać uwierzytelnianie powiązane z połączeniem lub spowodować awarię Traefika.

Traefik od wersji 3.7.0 przed 3.7.14 zawiera podatność obejścia uwierzytelniania w providerze Kubernetes Ingress-NGINX, który przekazuje nagłówki Ssl-Client-* dostarczone przez klienta na router HTTP w postaci jawnej. Gdy ssl-redirect jest wyłączony wraz z auth-tls-pass-certificate-to-upstream, nieuwierzytelnieni atakujący mogą wysłać Ssl-Client-Verify: SUCCESS z wybranym podmiotem i wystawcą certyfikatu, aby podszyć się pod tożsamości mTLS.

Traefik w wersjach 2.11.0–2.11.57 oraz 3.0.0–3.7.13 zawiera obejście uwierzytelniania polegające na tym, że pierwsze żądanie wstępnie uwierzytelnione tokenem Authorization: Negotiate uwierzytelnia gniazdo w globalnie współdzielonej puli połączeń backendu, która nigdy nie jest izolowana. Nieuwierzytelnieni atakujący na osobnych połączeniach frontendu mogą otrzymać to gniazdo powiązane z NTLM/Kerberos i wykonywać odczyty lub zapisy z tożsamością ofiary.

Traefik w wersji od 3.7.0 przed 3.7.14 zawiera podatność niewłaściwego uwierzytelniania w providerze Kubernetes Ingress NGINX, która łączy certyfikaty CA klienta, gdy nazwy auth-tls-secret kolidują po normalizacji kropek na myślniki. Atakujący posiadający certyfikaty z CA innego hosta mogą uzyskać dostęp do hosta wymagającego własnego CA klienta, podczas gdy legalni klienci tego hosta są odrzucani.

Traefik od wersji 3.2.0 przed 3.7.14 zawiera podatność obejścia uwierzytelniania w eksperymentalnej puli połączeń FastProxy, która nie przypisuje połączeń backendu uwierzytelnionych przez NTLM/Negotiate do ich połączenia frontendowego. Nieuwierzytelnieni klienci mogą otrzymać pulowane połączenie keep-alive backendu, w którym ofiara zakończyła uzgadnianie NTLM lub Negotiate, co pozwala im czytać dane ofiary i działać jako ofiara.

W Traefik w wersjach od 3.7.13 do 3.7.14 występuje obejście kontroli dostępu w providerze Kubernetes Ingress NGINX. Router HTTP generowany dla Ingressów z ssl-passthrough na punktach wejściowych bez TLS nie stosuje adnotacji kontroli dostępu, co pozwala nieuwierzytelnionym atakującym uzyskać dostęp do backendów chronionych przez auth-type, auth-url lub whitelist-source-range bez żadnego logowania.

Traefik przed wersją 2.11.58 i 3.7.14 zawiera podatność obejścia uwierzytelniania w sprawdzaniu SNI, które jest pomijane, gdy stan TLS żądania jest nil. Nieuwierzytelnieni klienci mogą wysyłać żądania HTTP/2 z pseudo-nagłówkiem :scheme http przez TLS w kompilacjach Go 1.27, aby dotrzeć do routerów wymagających certyfikatów klienta bez przedstawiania takiego certyfikatu.

W Traefik przed wersjami 2.11.46, 3.6.17 i 3.7.0 brak walidacji przestrzeni nazw dla adnotacji Ingress i Service w providerze Kubernetes Ingress. Atakujący mogący tworzyć lub aktualizować zasoby Ingress lub Service w jednej przestrzeni nazw mogą ustawić adnotacje router.middlewares lub service.serverstransport, aby uzyskać dane uwierzytelniające innego tenanta lub ponownie użyć jego certyfikatów klienta.

W Traefik od wersji 3.6.11 do 3.7.13 funkcja checkPassword w BasicAuth buduje klucz singleflight na podstawie przesłanego hasła i zapisanego sekretu. Równoległe żądania dla nieistniejących nazw użytkowników łączą się w jeden klucz, podczas gdy skonfigurowane nazwy użytkowników wykonują osobne hashowanie haseł, co tworzy nieuwierzytelnioną różnicę czasową ujawniającą istnienie nazwy użytkownika. Kolejne sprawdzenia pozostają wyrównane kosztowo, Traefik v2 i uwierzytelnianie Digest nie są dotknięte, a problem nie ujawnia poświadczeń ani nie omija uwierzytelniania.

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 3.2.0 do 3.7.13, mechanizmy obronne punktu wejścia aliasHeadersStrategy, underscoreHeadersStrategy i forwardedHeaders sprawdzają req.Header, ale nie req.Trailer, co pozwala nieuwierzytelnionemu klientowi na przesłanie nazwy nagłówka aliasującego lub zaufanego w trailerze HTTP/1.1 chunked lub HTTP/2. Gdy middleware retry lub buforujące odczytuje ciało przed sklonowaniem żądania przez reverse proxy, wartość trailera kontrolowana przez atakującego dociera do backendu, który scala trailery z przestrzenią nazw nagłówków, omijając udokumentowane zachowanie usuwania lub odrzucania i potencjalnie podszywając się pod tożsamość lub przekierowując dane routingu.

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.

Podatność w Traefik (wersje od 3.0.0 do 3.6.25 i 3.7.10) w dostawcy Kubernetes Gateway API. Konstrukcja tożsamości routerów i usług może powodować kolizje, umożliwiając nadpisanie backendu innej przestrzeni nazw.

Traefik od 3.6.11 do 3.6.25 i 3.7.10 ma podatność w middleware BasicAuth, która pozwala atakującemu z ważnym poświadczeniem i hashem uwierzytelnić się jako niekonfigurowana nazwa użytkownika.

W Traefik przed wersjami 2.11.54, 3.6.25 i 3.7.10, referencje @kubernetescrd między przestrzeniami nazw nie są odrzucane dla backendów TraefikService rozwiązywanych przez resolver usług. Użytkownik ograniczony przez RBAC do jednej przestrzeni nazw może podpiąć swój router do TraefikService z innej przestrzeni i ujawnić lub przekierować backend tej przestrzeni, łamiąc izolację narzuconą przez allowCrossNamespace=false.

Traefik w wersjach >= v3.7.0 i <= v3.7.7 zawiera podatność na path traversal w oprogramowaniu pośredniczącym RewriteTarget dostawcy Kubernetes Ingress NGINX (generowanym z adnotacji nginx.ingress.kubernetes.io/rewrite-target). Gdy ścieżka Ingress używa wyrażenia regularnego przechwytującego tekst kontrolowany przez atakującego bez wymagania separatora ścieżki (np. ścieżka /api(.*) z celem przepisania /$1), spreparowane żądanie, takie jak /api../admin, pasuje do publicznego routera, jest przepisywane na ścieżkę z przejściem kropkowym (/../admin) i przekazywane bez walidacji normalizacji po zastąpieniu. Backend, który normalizuje segmenty kropkowe, rozwiązuje ścieżkę do chronionego punktu końcowego (np. /admin) osiągalnego tylko przez oddzielny router zabezpieczony BasicAuth, DigestAuth lub ForwardAuth, co skutkuje obejściem uwierzytelniania na poziomie trasy. Problem został naprawiony w wersji v3.7.8.

Traefik 3.6.0-3.6.22 i 3.7.0-3.7.6 nie egzekwuje listy dozwolonych crossProviderNamespaces dla referencji serversTransport w IngressRouteTCP. Użytkownik Kubernetes z niskimi uprawnieniami w nieautoryzowanej przestrzeni nazw może ustawić serversTransport: foo@file, co pozwala na użycie dostawcy plików TCPServersTransport, w tym uprzywilejowanych certyfikatów klienta mTLS, tożsamości SPIFFE lub ustawień PROXY-protocol. Naprawione w 3.6.23 i 3.7.7.

Traefik w wersjach 3.7.0 do 3.7.6 zawiera podatność na pomylenie przestrzeni nazw w dostawcy Kubernetes Gateway API. Podczas rozwiązywania `HTTPRoute.spec.rules[].backendRefs[].filters[].extensionRef` Traefik używa przestrzeni nazw backendowego Serwisu zamiast przestrzeni nazw HTTPRoute. Osoba z niskimi uprawnieniami do tras, posiadająca ReferenceGrant dla Serwisu w innej przestrzeni nazw, może powiązać Middleware Traefika z przestrzeni nazw backendu bez osobnego grantu, potencjalnie wstrzykując zaufane nagłówki tożsamości reverse-proxy do żądań wychodzących. Problem został naprawiony w wersji 3.7.7.

Traefik w wersjach do 2.11.51, od 3.6.0 do 3.6.22 oraz od 3.7.0 do 3.7.6 zawiera podatność na ominięcie uwierzytelniania przez path traversal w middleware ReplacePathRegex. Niezautoryzowany atakujący może wysłać spreparowane żądanie, które po przetworzeniu przez middleware trafia do backendu bez walidacji normalizacji ścieżki, umożliwiając dostęp do chronionych zasobów.

Traefik w wersjach od 3.7.0 do 3.7.5 ma podatność w dostawcy Kubernetes Gateway API, gdzie dwa zaakceptowane HTTPRoute wskazujące na ten sam backend Service:port, ale z różnymi filtrami backendRef, mogą powodować zastosowanie tylko jednego zestawu filtrów do wszystkich żądań kierowanych do tego backendu. W rezultacie atakujący może narzucić swój kontekst filtru na żądania innej trasy, potencjalnie przekraczając granice przestrzeni nazw.

W Traefik przed wersjami v2.11.51, v3.6.22 i v3.7.6, middleware ForwardAuth, nawet przy ustawieniu trustForwardHeader: false, przekazuje nagłówek X-Forwarded-Port z oryginalnego żądania zamiast z przefiltrowanego. Nieuwierzytelniony atakujący może wstrzyknąć nagłówek X-Forwarded-Proto: https przez zwykłe połączenie HTTP, co powoduje przekazanie X-Forwarded-Port: 443 do serwisu uwierzytelniającego i ominięcie kontroli dostępu opartej na porcie.

Podatność w Traefik przed wersją 2.10.5 i 3.0.0-beta4 umożliwia atak DoS przez szybkie tworzenie i anulowanie strumieni HTTP/2 (technika Rapid Reset). Problem pochodzi z implementacji HTTP/2 w standardowej bibliotece Go.

W Traefik, w wersjach przed 2.11.43, 3.6.14 i 3.7.0-rc.2, wykryto podatność na ominięcie uwierzytelniania w middleware StripPrefixRegex używanym z ForwardAuth, BasicAuth lub DigestAuth. Problem wynika z niezgodności między dekodowaną ścieżką URL a surową ścieżką po obcięciu, co pozwala na przesłanie żądania z kropkowym segmentem (np. /./admin/secret) do backendu, który normalizuje go do chronionej ścieżki.

W Traefiku przed wersjami 2.11.42, 3.6.11 i 3.7.0-ea.3, gdy nagłówek `headerField` jest skonfigurowany z niekanoniczną nazwą (np. `x-auth-user` zamiast `X-Auth-User`), uwierzytelniony atakujący może wstrzyknąć własną kanoniczną wersję tego nagłówka, podszywając się pod dowolną tożsamość w systemie backendowym. Backend otrzymuje dwa wpisy nagłówka, a wstrzyknięty kanoniczny jest odczytywany jako pierwszy, nadpisując niekanoniczny wpis Traefika.

Podatność w Traefiku pozwala na wstrzyknięcie reguł routingu przez interpolację niesprawdzonych wartości użytkownika w dostawcy Knative. Atakujący może ominąć ograniczenia hosta i przekierować ruch do kontrolowanych przez siebie domen, co w środowiskach wielodostępnych prowadzi do nieautoryzowanego dostępu do usług ofiary.

Podatność w Traefiku umożliwia ominięcie uwierzytelniania wzajemnego TLS (mTLS) poprzez wysłanie sfragmentowanego pakietu ClientHello. Gdy fragmentacja uniemożliwia odczytanie SNI, router TCP przełącza się na domyślną konfigurację TLS, która nie wymaga certyfikatów klienckich.

W Traefik w wersjach od 2.11.9 do 2.11.37 oraz od 3.1.3 do 3.6.8 występuje podatność polegająca na nieprawidłowym porównywaniu wielkości liter w nagłówku Connection. Zdalny, nieuwierzytelniony atakujący może użyć małych liter w tokenach Connection, aby ominąć ochronę i usunąć zarządzane przez Traefik nagłówki X-Forwarded.