CVE-2026-63330

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 przed wersją 0.25.6 ma podatność w proxy HTTP, gdzie nagłówek x-warpgate-username dostarczony przez klienta jest przekazywany przed dodaniem uwierzytelnionego użytkownika. Ponieważ konstruktor żądań zachowuje powtórzone wartości, backend ufający pierwszej wartości może autoryzować uwierzytelnionego atakującego jako innego użytkownika. Podobnie akceptowany jest zarezerwowany nagłówek x-warpgate-authentication-type. Problem naprawiono w wersji 0.25.6.

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