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.

Affected: Go: github.com/amir20/dozzle

### 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](https://github.com/amir20/dozzle/blob/master/internal/support/container/agent_service.go#L27-L29)): ```go func (a *agentService) FindContainer(ctx context.Context, id string, labels container.ContainerLabels) (container.Container, error) { return a.client.FindContainer(ctx, id) } ```

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` co…