CVE-2026-24740 is a critical (CVSS 9.9) authorization flaw in Dozzle, the Docker log viewer. A user restricted by label filters can get an interactive root shell in out-of-scope containers on the same agent host. Versions up to 9.0.2 are affected. Upgrade to 9.0.3.
What's affected
The GitHub advisory lists Dozzle 9.0.2 and earlier as affected, with 9.0.3 patched. It says the issue was tested on 9.0.2 and likely affects all versions with agent mode support.
The setup that matters is Dozzle with simple authentication and per-user label filters in users.yaml, for example filtering a user to containers labeled env=dev. These filters are meant to limit which containers the user can see and use. The flaw is in the agent backed shell endpoints, where a user who targets container IDs directly can reach containers outside the filter, such as env=prod on the same agent host.
The attacker needs a valid login with low privileges.
How to check if you're exposed
Find the Dozzle version you run:
docker ps --filter ancestor=amir20/dozzle --format '{{.Names}} {{.Image}}'
Then check whether you rely on label filters in users.yaml to separate teams or environments, and whether agents run on hosts that also run production containers. If you do, you were depending on the control that fails.
For a quick look at your own dependencies, Safeguard's free in-browser dependency scan at https://gold.safeguard.sh/scan checks them against known CVEs in your browser.
What to do now
- Upgrade Dozzle, and its agents, to 9.0.3 or later.
- Do not treat label filters as a security boundary between dev and prod until you have upgraded.
- Run separate Dozzle instances and agents for production and non-production hosts.
- Review who has Dozzle accounts and remove the ones nobody needs.
- Check shell session records on production hosts if the old version was in use.
Why it matters
The record lists CWE-284, improper access control, and CWE-863, incorrect authorization. The filter was applied when listing containers, but the shell endpoint did not check it again, so knowing a container ID was enough. The general lesson is to enforce authorization at the action, not only at the menu.
A root shell is a large step from a log viewer, and in a container environment it often leads to secrets and network access. The CVE is not in CISA's Known Exploited Vulnerabilities catalog.
Why label filters are not a safe boundary
Dozzle's label filters are a convenience feature that people naturally start to use as a security control. Giving a developer a login that only shows containers labeled env=dev feels like access control. The advisory shows where that breaks: the filter was applied to what the user could list, but the shell endpoint accepted a container ID directly, and a known or guessable ID reached containers the filter was meant to hide.
Container IDs are not secrets. They show up in logs, in monitoring tools, in error messages and in the output of anyone with docker access on the host. Any control that depends on an ID staying unknown will not hold.
What to check on your side
Look at your users.yaml and ask what each account is meant to reach. For each user with a filter, list the environments sharing that agent host. If production and development containers run on the same host with the same agent, a filter was the only wall between them. After the upgrade, that wall is enforced where the action happens, but the better design is to not share the host at all.
Shell access deserves its own thought. A root shell in a container is often a step away from the secrets mounted into it, the network it sits on and sometimes the host itself, depending on how the container was started. Consider whether log viewing and shell access should be the same permission. Many teams need the first for developers and the second for almost nobody.
After the upgrade
Check shell session records or host audit logs for sessions into production containers by accounts that should only see development. Rotate secrets that production containers hold if you find any, or if you cannot rule it out. Then separate agents by environment, so that the next authorization bug has less to reach.
This pattern, a check at the list step but not at the action step, is common in admin tools. When you review any internal tool, try the same question: what happens if a user skips the menu and calls the action directly with an identifier they were not shown?
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Who can use this flaw?
A logged in user whose access is restricted by label filters, per the advisory.
Which version fixes it?
Dozzle 9.0.3.
Sources
Last reviewed: 19 October 2026.
