CVE-2026-102332

Cross-Site WebSocket Hijacking vulnerability in Dozzle prior to 10.5.2. The WebSocket upgrader for /exec and /attach endpoints accepts requests from any origin, and the JWT cookie uses SameSite: Lax. An attacker on the same site (e.g., a subdomain) can hijack the WebSocket session and gain interactive shell access to a container.

Dozzle is a realtime log viewer for docker containers. Prior to 10.6.7, streamEvents in internal/web/events.go applies a restricted user's label filter to container lists but not to the container-stat and container-event channels returned by GET /api/events/stream. In a simple-auth deployment using per-user filters, any authenticated restricted account can receive resource telemetry and lifecycle events for containers outside its authorized label scope. The exposed data includes container names, images, full label maps, CPU and memory use, network and disk totals, and deployment or restart activity across monitored hosts, but does not include log contents, environment values, or exec access. This issue is fixed in version 10.6.7.

Dozzle is a realtime log viewer for docker containers. From 10.5.2 until 10.6.15, the isBlockedIP SSRF guard in internal/notification/dispatcher/webhook.go, used by safeDialContext for webhook notification URLs, does not inspect IPv4 addresses embedded in 6to4, NAT64, Teredo, or IPv4-compatible IPv6 addresses, allowing an authenticated user to reach loopback or link-local targets that the guard intends to block. This issue is fixed in version 10.6.15.

In Dozzle before version 10.5.2, in the default configuration (no DOZZLE_AUTH_PROVIDER set), the POST /api/notifications/test-webhook endpoint is accessible without authentication. An attacker can supply an arbitrary URL, and Dozzle will send an HTTP POST with controlled headers and return the response (status code and up to 1MB of body) to the attacker.