CVE-2026-109469

Chartbrew w wersjach 4.8.5–5.2.2 pozwala uwierzytelnionemu użytkownikowi z uprawnieniami do zarządzania połączeniami API ustawić pole allowPrivateHost, omijając ograniczenia dostępu do sieci prywatnych i zarezerwowanych. Migracja aktualizacyjna włącza to obejście także dla istniejących połączeń, a ustawienie per-połączenie ma pierwszeństwo nad CB_ALLOW_PRIVATE_NETWORK_CALLS. Udana eksploatacja umożliwia wysyłanie żądań do wewnętrznych usług HTTP osiągalnych z serwera Chartbrew.

UgCS server przed wersją 6.2 zawiera obejście uwierzytelniania w obsłudze logowania protokołu HCI (LoginHandler) na porcie TCP 3334. Gdy baza użytkowników zawiera dokładnie jednego użytkownika, żądanie logowania z pustymi polami userLogin i userPassword jest interpretowane jako użycie jedynego użytkownika i serwer zwraca w pełni uwierzytelnioną sesję. Usługa domyślnie nasłuchuje na wszystkich interfejsach (0.0.0.0) bez TLS.

JupyterLab Desktop przed wersją 4.6.2-1 udostępniało funkcję getServerInfo rendererowi bez potwierdzenia, że bieżąca strona nadal pochodzi z lokalnego serwera Jupyter. W lokalnej sesji zarządzanej z JupyterLab przed 4.4.8 atakujący może umieścić spreparowany link MathJax w niezaufanym notatniku; po kliknięciu ofiara przechodzi na stronę atakującego, która zachowuje dostęp do mostka preload i może pobrać URL serwera oraz token uwierzytelniający, a następnie utworzyć i zaufać notatnikowi wykonującemu dowolny kod.

Chartbrew przed wersją 5.2.3 montował administracyjny panel BullMQ (Bull Board) pod ścieżką /apps/queues bez sprawdzania uwierzytelnienia. Zdalny nieuwierzytelniony atakujący, który może dotrzeć do tej ścieżki na instancji z włączonym Redis i BullMQ oraz bez blokady w reverse proxy, może przeglądać ładunki zadań i logi, a w zależności od wersji i stanu kolejek ponawiać lub usuwać zadania oraz zmieniać przetwarzanie kolejek.

Chartbrew przed wersją 5.2.3 posiadał cztery mechanizmy uwierzytelniania akceptujące tokeny sesji podpisane kluczem CB_SECRET, w tym znanymi, słabymi lub domyślnymi wartościami. W instalacjach ze źródła lub z repozytorium Docker Compose z domyślnym CB_SECRET atakujący może sfałszować token HS256 wskazujący na wybranego użytkownika i podszyć się pod niego bez hasła i 2FA w całym API i warstwie socketów.

2FAuth przed wersją 8.0.0 przy włączonym AUTHENTICATION_GUARD=reverse-proxy-guard odczytuje domyślny nagłówek tożsamości REMOTE_USER lub niestandardowy nagłówek wskazany w AUTH_PROXY_HEADER_FOR_USER bez potwierdzenia, że żądanie pochodzi z zaufanego proxy. Zdalny klient mogący dotrzeć bezpośrednio do aplikacji może sfałszować nagłówek tożsamości i uwierzytelnić się jako istniejący użytkownik, w tym administrator.

2FAuth przed wersją 8.0.0 przy AUTHENTICATION_GUARD=reverse-proxy-guard akceptuje nagłówki uwierzytelniania od klienta, który nie przeszedł przez zaufane proxy; RemoteUserProvider::retrieveById() tworzy konto dla nieznanego REMOTE_USER, awansuje pierwsze utworzone konto na administratora i synchronizuje e-mail z nagłówka poczty. Nieuwierzytelniony zdalny klient może utworzyć administratora na świeżej instancji lub podszyć się pod znane konto i przekierować jego e-mail.

Chartbrew przed wersją 5.2.1 niebezpiecznie używał kontrolowanych przez atakującego ciągów zamiany JavaScript w podstawianiu zmiennych dashboardu SQL oraz nie escapował backslashy w kontekstach cytowanych dla MySQL i MariaDB. Nieuwierzytelniony użytkownik wysyłający spreparowane wartości filtrów URL do publicznego lub osadzonego wykresu opartego na zapisanym zapytaniu SQL może wstrzyknąć SQL i odczytać, zmodyfikować lub usunąć dane dostępne dla konta bazy danych.

JupyterLab Desktop przed wersją 4.6.2-1 wstawiał adresy URL zdalnych serwerów do okna wyboru serwera i widoku Welcome bez bezpiecznego kodowania. Atakujący, który nakłoni użytkownika do przesłania spreparowanego URL, może wykonać JavaScript w rendererze Welcome i wykorzystać uprzywilejowany mostek IPC do wykonania dowolnego kodu z uprawnieniami użytkownika; osobna ścieżka dotyczy niebezpiecznego renderowania tytułów kanału RSS.

W wdrożeniach Tracecat opartych na Docker Compose z włączonym SAML, w wersjach od 0.37.0 do 1.0.0-beta.49, zmienne SAML_SIGNED_ASSERTIONS i SAML_SIGNED_RESPONSES mogą być puste, co wyłącza wymóg podpisywania asercji i odpowiedzi SAML. Nieuwierzytelniony atakujący może przesłać sfałszowaną niepodpisaną odpowiedź SAML dla istniejącego adresu e-mail użytkownika i przejąć jego sesję, w tym konto superadministratora.