CVE-2026-102332

Podatność Cross-Site WebSocket Hijacking w Dozzle przed wersją 10.5.2. WebSocket upgrader dla endpointów /exec i /attach akceptuje żądania z dowolnego pochodzenia, a ciasteczko JWT używa SameSite: Lax. Atakujący z tej samej domeny (np. subdomena) może przejąć sesję WebSocket i uzyskać interaktywny dostęp do powłoki w kontenerze.

Dozzle to przeglądarka logów w czasie rzeczywistym dla kontenerów Docker. Przed wersją 10.6.7 funkcja streamEvents w pliku internal/web/events.go stosuje filtr etykiet ograniczonego użytkownika do list kontenerów, ale nie do kanałów statystyk kontenerów i zdarzeń kontenerów zwracanych przez GET /api/events/stream. W prostym wdrożeniu uwierzytelniania z filtrami na użytkownika każde uwierzytelnione konto o ograniczonym zakresie może otrzymywać dane telemetryczne i zdarzenia cyklu życia dla kontenerów poza swoim autoryzowanym zakresem etykiet. Ujawnione dane obejmują nazwy kontenerów, obrazy, pełne mapy etykiet, użycie CPU i pamięci, sumy sieciowe i dyskowe oraz aktywność wdrożeń lub restartów na monitorowanych hostach, ale nie obejmują zawartości logów, wartości środowiskowych ani dostępu exec. Problem naprawiono w wersji 10.6.7.

Dozzle to przeglądarka logów w czasie rzeczywistym dla kontenerów Docker. Od wersji 10.5.2 do 10.6.15, ochrona SSRF isBlockedIP w internal/notification/dispatcher/webhook.go, używana przez safeDialContext dla adresów URL powiadomień webhook, nie sprawdza adresów IPv4 osadzonych w adresach IPv6 6to4, NAT64, Teredo lub kompatybilnych z IPv4, co pozwala uwierzytelnionemu użytkownikowi na dotarcie do celów loopback lub link-local, które ochrona ma blokować. Problem został naprawiony w wersji 10.6.15.

W Dozzle przed wersją 10.5.2, w domyślnej konfiguracji (bez DOZZLE_AUTH_PROVIDER), punkt końcowy POST /api/notifications/test-webhook jest dostępny bez uwierzytelnienia. Atakujący może wysłać żądanie z dowolnym URL-em, a Dozzle wyśle do niego żądanie HTTP POST z kontrolowanymi nagłówkami i zwróci odpowiedź (kod statusu oraz do 1MB treści) atakującemu.