CVE-2026-24740: 
vulnerability analysis and mitigation

CVE-2026-24740 is a label-based access control bypass vulnerability in Dozzle, a real-time log viewer for Docker containers. It affects all versions of Dozzle prior to 9.0.3 that support agent mode. The flaw allows an authenticated user restricted to a specific label set (e.g., env=dev) who holds the Shell role to gain an interactive root shell in out-of-scope containers (e.g., env=prod) on the same agent host by directly targeting their container IDs. The vulnerability was published on January 26, 2026, and patched in version 9.0.3 released the same day. It carries a CVSS v3.1 base score of 9.9 (Critical) and a CVSS v4.0 base score of 8.7 (High) (Github Advisory, Dozzle Advisory).

The root cause is improper access control (CWE-284) and incorrect authorization (CWE-863) in Dozzle's agent-backed FindContainer implementation. When SIMPLE auth is enabled, per-user label filters defined in users.yaml are correctly applied to container listing (ListContainers), but the agentService.FindContainer function in agent_service.go previously called a.client.FindContainer(ctx, id) without passing the caller's userLabels, effectively ignoring label-scope enforcement. An authenticated attacker with the Shell role can exploit this by directly calling the WebSocket endpoints /api/hosts/{hostId}/containers/{containerId}/exec or /attach with a valid JWT and a known out-of-scope container ID, bypassing the label filter entirely. The attack requires network access to the Dozzle instance, a valid user account with the Shell role, and knowledge of the target container ID — no additional privileges or user interaction are needed (Dozzle Advisory, Patch Commit).

Successful exploitation grants an attacker a full interactive root shell inside containers that should be inaccessible based on their label-based access restrictions, breaking multi-tenant or multi-environment isolation on shared agent hosts. The attacker can read sensitive data from production containers, modify container configurations or running processes, and disrupt services — all with root-level privileges inside the target container. This creates significant risk of lateral movement across environment boundaries (e.g., from dev to prod), data exfiltration, and service disruption without any additional privilege escalation steps (Dozzle Advisory, Github Advisory).

A detailed proof-of-concept (PoC) is publicly available in the official security advisory, demonstrating the full exploit chain using wscat to establish a WebSocket shell session into an out-of-scope container. The EPSS score is approximately 0.026% (8th percentile), indicating low predicted exploitation probability in the near term. There is no evidence of active in-the-wild exploitation or threat actor attribution at this time, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (Dozzle Advisory, Github Advisory).

1. Reconnaissance: Identify a Dozzle instance (version ≤ 9.0.2) running in agent mode with SIMPLE auth enabled and at least one user account configured with both a label filter (e.g., filter: label=env=dev) and the shell role.
2. Authenticate: Obtain a valid JWT by authenticating as the constrained user via curl -s -X POST http://<dozzle-host>:8080/api/token -d 'username=devuser&password=devpass' -c cookies.txt and extract the JWT cookie value.
3. Identify the agent host ID: Browse the Dozzle UI or inspect API responses to obtain the agent host ID (e.g., cafb9ffc-ac34-47a6-985b-10ffea39610e).
4. Obtain the target container ID: Discover the container ID of an out-of-scope container (e.g., env=prod) through any available means — Docker API access, logs, or side-channel information — since it will not appear in the Dozzle UI for the constrained user.
5. Open unauthorized shell: Use wscat or any WebSocket client to connect directly to the exec endpoint, bypassing label enforcement: wscat -c 'ws://<dozzle-host>:8080/api/hosts/<HOST_ID>/containers/<PROD_CID>/exec' -H 'Cookie: jwt=<TOKEN>'.
6. Execute commands as root: Send JSON-formatted input such as {"type":"userinput","data":"id\n"} to execute arbitrary commands inside the target container as uid=0(root) (Dozzle Advisory).

• Network: Unexpected WebSocket upgrade requests to /api/hosts/{hostId}/containers/{containerId}/exec or /api/hosts/{hostId}/containers/{containerId}/attach from users whose label filters should not permit access to the targeted container ID.
• Logs: Dozzle access logs showing WebSocket connections to exec/attach endpoints for container IDs that do not match the authenticated user's configured label filter (e.g., a user with filter: label=env=dev accessing a container labeled env=prod).
• Logs: JWT authentication events followed immediately by direct API calls to exec/attach endpoints without corresponding container list API calls (indicating direct container ID targeting rather than UI navigation).
• Process: Unexpected commands executed inside production containers (e.g., id, cat /etc/hostname, env, reverse shell commands) originating from Dozzle's exec session rather than normal application processes.
• File System: New files, scripts, or modified configurations inside containers that should not have been interactively accessed by the affected user account (Dozzle Advisory).

Upgrade Dozzle to version 9.0.3 or later, which fixes the vulnerability by passing userLabels through the agent-backed FindContainer call, enforcing the same label-scope filtering as the listing API (Dozzle v9.0.3 Release, Patch Commit). Until patching is complete, mitigate by: (1) removing the Shell role from users who rely on label-based isolation for security boundaries; (2) implementing network-level controls to restrict access to Dozzle's API endpoints; and (3) avoiding use of agent mode with SIMPLE auth label filters as a security boundary in multi-tenant environments. Monitor for unauthorized exec/attach WebSocket sessions as described in the IOCs section (Dozzle Advisory).

The vulnerability was reported by security researcher k14uz and disclosed responsibly through GitHub's security advisory process. The fix was released the same day as disclosure (January 26, 2026), reflecting a rapid vendor response. Community reaction on platforms such as Bluesky noted the severity of the bypass given its potential impact on multi-tenant Docker environments. No major media coverage or significant vendor statements beyond the official advisory have been identified (Dozzle Advisory, Dozzle v9.0.3 Release).