CVE-2026-63329

Warpgate to open-source'owy bastion SSH, HTTPS i MySQL dla Linuksa. Przed wersją 0.25.5 endpoint /@warpgate/api/sso/providers/:name/start przechowuje kontrolowany przez atakującego parametr next, który handler POST /@warpgate/api/sso/return wstawia bez escapowania HTML do odpowiedzi generowanej przez warpgate-protocol-http/src/api/sso_provider_list.rs. Ofiara, która kliknie spreparowany link i ukończy SSO, może spowodować wykonanie znaczników i JavaScriptu w uwierzytelnionym originie Warpgate, co umożliwia dostęp do danych sesji i działań przez API użytkownika, a przez API administratora tylko gdy ofiara jest administratorem. Ścieżka GET /@warpgate/api/sso/return również używa tej samej niezwalidowanej wartości jako celu przekierowania, umożliwiając otwarte przekierowanie.

Warpgate to otwartoźródłowy bastion SSH, HTTPS i MySQL dla Linux. Od wersji 0.21.0 do 0.29.0 korelator żądań Kubernetes w warpgate-protocol-kubernetes/src/correlator.rs identyfikuje autoryzowany AdmittedTarget po nazwie użytkownika, nazwie celu i adresie IP klienta, a nie po niezmiennym UUID użytkownika, podczas gdy KubernetesSessionHandle::close nie usuwa wpisu. Jeśli konto zostanie usunięte, a inne konto o niskich uprawnieniach zostanie utworzone z tą samą nazwą użytkownika, konto zastępcze może uwierzytelnić się jako odtworzona nazwa użytkownika i ponownie użyć wciąż aktywnego wpisu korelacji poprzednika przy żądaniu tego samego celu z tego samego adresu IP klienta przed wygaśnięciem kubernetes.session_max_age. Uwierzytelnianie bieżącego żądania nadal występuje, ale ponownie użyty wpis omija świeżą kontrolę autoryzacji celu i może spowodować, że Warpgate będzie pośredniczyć w żądaniach z poświadczeniami celu Kubernetes, których konto zastępcze nie jest upoważnione do używania, ujawniając zasoby klastra lub umożliwiając nieautoryzowane modyfikacje. Problem naprawiono w wersji 0.29.0.

Warpgate to otwartoźródłowy host bastionu SSH, HTTPS i MySQL dla Linuksa. W wersjach przed 0.29.0 listener protokołu Kubernetes używa AcceptAnyClientCert w warpgate-protocol-kubernetes/src/server/client_certs.rs do akceptowania certyfikatów na warstwie TLS i odracza walidację do warpgate-protocol-kubernetes/src/server/auth.rs, gdzie błędy uwierzytelniania i wyszukiwania są renderowane dosłownie w treści odpowiedzi HTTP 500. Aplikacja Kubernetes w warpgate-protocol-kubernetes/src/server/mod.rs nie ma zewnętrznego wrappera logowania żądań używanego przez protokół HTTP, a błędy w warpgate-protocol-kubernetes/src/server/handlers.rs mogą zakończyć się przed wewnętrznym punktem logowania. Nieuwierzytelniony klient sieciowy może zatem wywołać błędy i otrzymać diagnostykę parsera ASN.1/DER lub błędy bazy danych sea_orm bez zapisania próby w logu bramy. Ujawnione informacje ograniczają się do wewnętrznej diagnostyki, a wpływ na dane użytkownika, integralność lub dostępność nie został ustalony. Problem został naprawiony w wersji 0.29.0.

W Warpgate przed wersją 0.28.4 endpoint PUT /@warpgate/admin/api/users/:id/roles/:role_id nie wymaga uprawnienia AdminPermission::AccessRolesAssign. Ograniczony administrator z dowolnym uprawnieniem może zaktualizować expires_at istniejącego przypisania roli i wyczyścić revoked_at, wydłużając wygasające uprawnienie lub przywracając odebrane.

Warpgate do wersji 0.27.6 włącznie ma podatność w ścieżce SSH przez przeglądarkę, gdzie klucz hosta skoku (jump host) jest zapisywany dla adresu docelowego. W trybach Prompt i AutoAccept maszyna prezentująca klucz skoku na adresie docelowym może zostać zaakceptowana jako cel, co pozwala na przechwycenie ruchu użytkownika i nowo wydanego certyfikatu przy uwierzytelnianiu certyfikatowym. Natywna ścieżka SSH nie jest dotknięta, ponieważ śledzi każdy skok osobno. Problem naprawiono w wersji 0.27.6.

W Warpgate ścieżka powrotu SSO response_mode=form_post w sso_provider_list.rs używa serde_json::to_string bez neutralizacji sekwencji zamykającej skrypt. Wartość może trafić do bloku script przez kontrolowany przez atakującego parametr next lub przez komunikaty błędów IdP konkatenowane bez kodowania URL. Ścieżka IdP jest osiągalna, gdy atakujący kontroluje skonfigurowanego dostawcę tożsamości lub kontroluje roszczenie email/username na swoim koncie. Ofiara musi ukończyć przepływ form_post SSO, aby wstrzyknięty znacznik został wyrenderowany. CSP Warpgate blokuje wstrzyknięty JavaScript, więc skutkiem jest podszywanie się pod treść, fałszywy formularz logowania lub meta refresh. Problem naprawiono w wersji 0.27.6.

Warpgate do wersji 0.27.3 włącznie ma podatność w uwierzytelnianiu tokenem API HTTP, gdzie walidacja tokenu nie egzekwuje ograniczeń allowed_ip_ranges właściciela tokenu. Atakujący posiadający wyciekły, wyłudzony lub wykradziony token X-Warpgate-Token może go użyć z zabronionej lokalizacji sieciowej. Wdrożenia bez allowed_ip_ranges nie są dotknięte, a inne ścieżki (HTTP target proxying, SSH, MySQL, PostgreSQL, RDP, VNC, Kubernetes) nie akceptują tej podatnej ścieżki tokenu HTTP. Problem naprawiono w wersji 0.27.3.

Warpgate, open source bastion host SSH, HTTPS i MySQL dla Linuksa, w wersjach przed 0.25.6 posiada podatność w api_get_recording_stream w warpgate-admin/src/api/recordings_detail.rs. Endpoint /@warpgate/admin/api/recordings/{uuid}/stream jest chroniony tylko uwierzytelnieniem sesji, bez wymagania uprawnień administratora do przeglądania nagrań. Każdy uwierzytelniony zwykły użytkownik może subskrybować WebSocket aktywnego nagrania i odbierać w czasie rzeczywistym dane wejściowe i wyjściowe terminala z sesji SSH, MySQL lub PostgreSQL, w tym poświadczenia i polecenia.

W Warpgate przed wersją 0.23.3 przepływ SSO nie waliduje parametru state, co pozwala atakującemu nakłonić użytkownika do zalogowania się na konto atakującego. Może to skłonić ofiarę do wykonania wrażliwych działań na koncie atakującego.

Warpgate to bastion host SSH, HTTPS i MySQL dla systemu Linux, który nie wymaga specjalnych aplikacji klienckich. Atakujący może uwierzytelnić się jako inny użytkownik, jeśli loguje się użytkownik z włączonym SSO, a konto nie ma włączonego drugiego czynnika uwierzytelnienia.