Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/amir20/dozzle < 1.29.1-0.20260622172006-19c01e0fb491
Fixed in
1.29.1-0.20260622172006-19c01e0fb491· Vendor fix available
Issue
Dozzle supports per-user label filters in users.yml that are documented as an access-control boundary: "Filters are used to restrict the containers that a user can see" and "the guest user can only see containers with the label com.example.app … useful for restricting access to specific containers" (docs/guide/authentication.md). This is the mechanism operators use to give different users/tenants visibility into disjoint subsets of containers on the same host. The events stream handler streamEvents (GET /api/events/stream) honors that filter for the initial container list and for the incremental containers-changed updates, but it forwards two other channels — container-stat (live per-container CPU, memory, network and disk telemetry) and container-event (container lifecycle events: start/die/destroy/rename/pause/unpause, with the container's full attribute/label set) — to every authenticated client unconditionally, with no comparison against the caller's label filter. The…
Recommended action: Upgrade to 1.29.1-0.20260622172006-19c01e0fb491 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/amir20/dozzle < 1.29.1-0.20260804193351-8cf7ccd5ee04
Fixed in
1.29.1-0.20260804193351-8cf7ccd5ee04· Vendor fix available
Issue
The isBlockedIP SSRF guard in Dozzle's webhook notification dispatcher blocks loopback, link-local, multicast, and unspecified addresses but does not recognize IPv6 transition mechanism addresses (RFC 3056 6to4, RFC 6052 NAT64, RFC 4380 Teredo) that embed arbitrary IPv4 addresses. An authenticated user can bypass the guard to reach loopback services, cloud metadata endpoints (169.254.169.254), and other blocked ranges via webhook notification URLs. Affected component / versions - Package: github.com/amir20/dozzle - Affected versions: all versions with SSRF guard (current HEAD b9df313) - Vulnerable code: internal/notification/dispatcher/webhook.go Details Root cause (CWE-918) internal/notification/dispatcher/webhook.go:32-51: The guard intentionally allows RFC 1918 private ranges for self-hosted webhook targets, but blocks loopback (127.0.0.0/8, ::1), link-local (169.254.0.0/16, fe80::/10), and other non-routable addresses. IPv6 transition mechanism addresses bypass all these…
Recommended action: Upgrade to 1.29.1-0.20260804193351-8cf7ccd5ee04 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/amir20/dozzle < 1.29.1-0.20260125230338-620e59aa2463
Fixed in
1.29.1-0.20260125230338-620e59aa2463· Vendor fix available
Issue
A flaw in Dozzle’s agent-backed shell endpoints allows a user restricted by label filters (for example, label=env=dev) to obtain an interactive root shell in out‑of‑scope containers (for example, env=prod) on the same agent host by directly targeting their container IDs. Note: Tested on v9.0.2 likely affects all versions with agent mode support. Details When SIMPLE auth is enabled, Dozzle supports per‑user label filters in users.yaml (for example, filter: label=env=dev) to restrict which containers a user can see and interact with. These filters are propagated into the shell handlers, which resolve the target container via h.hostService.FindContainer(hostKey(r), id, userLabels) in both the attach and exec WebSocket endpoints, intending to limit shell access to containers within the user’s label scope. For agent-backed hosts, the corresponding implementation ignores the label scope when resolving a container by ID (agentservice.go#L27-L29): As a result, an authenticated user…
Recommended action: Upgrade to 1.29.1-0.20260125230338-620e59aa2463 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The app uses sha-256 as the hash for passwords. The app should switch to bcrypt. Details SHA-256 is a message digest hash, and not classified as secure for password hashing. Message digest hashes are designed to be fast, while password hashing mechanisms are designed with certain cryptographic properties (e.g. slow) to protect against vulnerabilities. Refer to the links below for more information: - https://security.stackexchange.com/questions/195563/why-is-sha-256-not-good-for-passwords - https://stackoverflow.com/questions/11624372/best-practice-for-hashing-passwords-sha256-or-sha512 - https://cheatsheetseries.owasp.org/cheatsheets/PasswordStorageCheatSheet.html#pre-hashing-passwords-with-bcrypt PoC N/A Impact It leaves users susceptible to rainbow table attacks
Recommended action: Upgrade to 8.5.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.