Описание
Dozzle Agent Label-Based Access Control Bypass Allows Unauthorized Container Shell Access
Summary
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 (agent_service.go#L27-L29):
As a result, an authenticated user configured with filter: label=env=dev and granted the shell role cannot see env=prod containers in the UI, but can still establish an interactive exec session into an env=prod container by calling /api/hosts/{hostId}/containers/{containerId}/exec (or /attach) with a valid JWT and the target container ID. This discrepancy between listing and exec/attach behavior breaks the intended label‑based isolation between environments or tenants for agent-backed deployments.
Note: The underlying Docker client implementation explicitly documents that FindContainer skips filters (docker/client.go#L128-L137):
Note: For reference, we can see the correct implementation in ListContainers (agent_service.go#L43-L46):
PoC
As configured, devuser only sees dev-allowed in the Dozzle UI (due to filter: label=env=dev), but can still open a root shell in prod-secret via the agent-backed exec endpoint by supplying its container ID.
Impact
This is an authorization bypass in environments that rely on SIMPLE auth label filters together with agents to separate environments or tenants. A user who should be constrained to a specific label set (for example, env=dev) but has the Shell role can gain full interactive access (read, modify, disrupt) to containers with other labels (for example, env=prod) on the same agent host, provided they can obtain the target container ID.
Remediation
-
In the agent-backed
FindContainerimplementation, enforce the same label-based filtering semantics as the Docker/Kubernetes host implementations by ensuring the requested (host, containerId) is within the set returned byListContainersfor the caller’suserLabelsbefore returning it to exec/attach. -
Add regression tests verifying that a user with filter:
label=env=devand the Shell role cannot exec or attach intoenv=prodcontainers via the agent path, even when supplying a valid container ID. -
As defense in depth, reject exec/attach requests when the resolved container is not present in the user-visible subset returned by the list API under the same label filter.
This issue has been fixed in version 9.0.3 but the Go registry only contains versions up to 1.29.0. Use Docker or GitHub to download 9.0.3.
Resources
Пакеты
github.com/amir20/dozzle
< 1.29.1-0.20260125230338-620e59aa2463
1.29.1-0.20260125230338-620e59aa2463
Связанные уязвимости
Dozzle is a realtime log viewer for docker containers. Prior to version 9.0.3, 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. Version 9.0.3 contains a patch for the issue.