Podatności Traefik

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.

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.

W Traefiku przed wersjami 2.11.38 i 3.6.9 wykryto podatność w zarządzaniu uzgadnianiem TLS na routerach TCP. Nieuwierzytelniony atakujący może wysłać niekompletny rekord TLS i zatrzymać transmisję, powodując zawieszenie uzgadniania i otwarcie połączenia na czas nieokreślony.

Podatność w Traefik przed wersją 3.6.8 umożliwia nieuwierzytelnionemu klientowi ominięcie limitu czasu odczytu (readTimeout) poprzez wysłanie 8-bajtowego preludium Postgres SSLRequest (STARTTLS), a następnie wstrzymanie transmisji. Powoduje to pozostawanie połączeń otwartych w nieskończoność, prowadząc do odmowy usługi (DoS).