CVE-2026-24740 Overview
Dozzle is a realtime log viewer for Docker containers. A critical authorization bypass vulnerability exists in versions prior to 9.0.3, where a flaw in Dozzle's agent-backed shell endpoints allows users 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.
This vulnerability represents a significant breach of Dozzle's access control model, enabling unauthorized container access across environment boundaries. Organizations relying on Dozzle's label-based filtering for security segregation are at risk of complete containment bypass.
Critical Impact
A restricted user can bypass label-based access controls to gain root shell access to any container on the same agent host, enabling full compromise of production containers from a development-scoped account.
Affected Products
- Dozzle versions prior to 9.0.3
- Dozzle agent-backed deployments with label-based access restrictions
- Multi-environment Dozzle configurations relying on label filters for security isolation
Discovery Timeline
- January 27, 2026 - CVE-2026-24740 published to NVD
- January 29, 2026 - Last updated in NVD database
Technical Details for CVE-2026-24740
Vulnerability Analysis
This vulnerability is classified under CWE-284 (Improper Access Control), stemming from an authorization bypass in Dozzle's agent-backed container lookup mechanism. The flaw allows authenticated users with label-restricted permissions to escape their designated access scope by directly targeting container IDs.
The core issue lies in the FindContainer function within the agent client implementation. When a restricted user requests access to a container via the shell endpoint, the function fails to enforce the user's assigned label filters during the container lookup operation. This means that while the user interface may only display containers matching their assigned labels (e.g., env=dev), the backend API accepts any valid container ID without validating it against the user's permission scope.
The attack requires network access and low-privilege authentication, but involves no user interaction. An attacker with valid credentials and restricted label-based access can simply obtain or guess container IDs for out-of-scope containers, then request shell access to those containers directly through the API. The result is an interactive root shell in containers the attacker should not have access to.
Root Cause
The vulnerability originates from the agentService.FindContainer function in internal/support/container/agent_service.go, which passes the container ID to the client's FindContainer method without forwarding the user's label filter constraints. The client-side function in internal/agent/client.go similarly accepts only the container ID, constructing a gRPC request without any filter parameters.
This architectural oversight means that while Dozzle's UI layer correctly filters visible containers based on user labels, the underlying container resolution mechanism has no awareness of these restrictions. The security model breaks down at the API boundary where container IDs bypass the label-based access control entirely.
Attack Vector
The attack vector is network-based with low complexity. An attacker exploits this vulnerability through the following sequence:
- Authenticate to Dozzle with a restricted account (e.g., label filter env=dev)
- Enumerate or obtain container IDs for out-of-scope containers (e.g., production containers with env=prod)
- Directly request shell access to the target container ID via Dozzle's agent-backed shell endpoint
- Gain interactive root shell access to the unauthorized container
The vulnerability enables both confidentiality and integrity impacts, as the attacker gains full root shell access to containers outside their permitted scope.
The following patch shows how the fix addresses the vulnerability by propagating label filters to the container lookup:
Patch in internal/agent/client.go:
}
}
-func (c *Client) FindContainer(ctx context.Context, containerID string) (container.Container, error) {
- response, err := c.client.FindContainer(ctx, &pb.FindContainerRequest{ContainerId: containerID})
+func (c *Client) FindContainer(ctx context.Context, containerID string, labels container.ContainerLabels) (container.Container, error) {
+ in := &pb.FindContainerRequest{ContainerId: containerID}
+
+ if labels != nil {
+ in.Filter = make(map[string]*pb.RepeatedString)
+ for k, v := range labels {
+ in.Filter[k] = &pb.RepeatedString{Values: v}
+ }
+ }
+
+ response, err := c.client.FindContainer(ctx, in)
if err != nil {
return container.Container{}, err
}
Source: GitHub Commit 620e59aa
Patch in internal/support/container/agent_service.go:
}
func (a *agentService) FindContainer(ctx context.Context, id string, labels container.ContainerLabels) (container.Container, error) {
- return a.client.FindContainer(ctx, id)
+ return a.client.FindContainer(ctx, id, labels)
}
func (a *agentService) RawLogs(ctx context.Context, container container.Container, from time.Time, to time.Time, stdTypes container.StdType) (io.ReadCloser, error) {
Source: GitHub Commit 620e59aa
Detection Methods for CVE-2026-24740
Indicators of Compromise
- Shell session requests to container IDs that do not match the requesting user's assigned label filters
- Abnormal access patterns where restricted users access containers outside their designated environment scope
- API requests to shell endpoints with container IDs for production containers from development-scoped accounts
- Audit log entries showing container access that violates the expected label-based segregation policy
Detection Strategies
- Implement API-level logging that correlates container ID requests with user label restrictions to identify mismatched access attempts
- Monitor for shell session establishments to containers that should be inaccessible based on user permissions
- Deploy network-level monitoring to detect unusual patterns of container ID enumeration or probing
- Review Dozzle access logs for evidence of cross-environment container access by label-restricted users
Monitoring Recommendations
- Enable verbose logging on Dozzle agent endpoints to capture all container access requests with full user context
- Configure alerts for any shell access requests where the target container's labels do not intersect with the user's permitted labels
- Establish baseline access patterns for each user role and alert on deviations indicating potential authorization bypass attempts
- Integrate Dozzle access logs with SIEM solutions for correlation with other container orchestration events
How to Mitigate CVE-2026-24740
Immediate Actions Required
- Upgrade Dozzle to version 9.0.3 or later immediately to address this authorization bypass vulnerability
- Audit existing Dozzle deployments to identify any instances using label-based access restrictions that may have been compromised
- Review container access logs for evidence of unauthorized cross-environment access prior to patching
- Consider temporarily disabling shell access functionality in Dozzle until the patch is applied in sensitive environments
Patch Information
The vulnerability is addressed in Dozzle version 9.0.3. The fix modifies the FindContainer function to accept and enforce user label filters during container lookup operations, ensuring that container ID-based access respects the user's permission scope.
Patch resources:
Workarounds
- Disable shell access functionality in Dozzle by removing or restricting the shell endpoint until patching is complete
- Implement network-level segmentation to isolate Dozzle agents serving different environment tiers (dev, staging, prod)
- Deploy additional authentication layers or API gateways in front of Dozzle to enforce container access policies independently
- Use separate Dozzle instances per environment rather than relying solely on label-based filtering for security isolation
# Upgrade Dozzle to patched version
docker pull amir20/dozzle:v9.0.3
# Restart Dozzle container with updated image
docker stop dozzle
docker rm dozzle
docker run -d --name dozzle -v /var/run/docker.sock:/var/run/docker.sock -p 8080:8080 amir20/dozzle:v9.0.3
# Verify version
docker logs dozzle | grep -i version
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
