CVE-2026-44985 is a critical (CVSS 9.6) cross-site WebSocket hijacking flaw in Dozzle, the realtime Docker log viewer. Versions before 10.5.2 accept WebSocket upgrades from any origin on the exec and attach endpoints. The fix is Dozzle 10.5.2, which rejects cross-origin upgrades.
What's affected
The NVD record says every Dozzle release prior to 10.5.2 is affected. The GitHub advisory lists the affected range as 10.5.1 and below. The 10.5.2 release notes list a bug fix titled "Reject cross-origin WebSocket upgrades on attach/exec."
One oddity: the advisory page I fetched shows no patched version in its metadata, while the NVD record and the release notes both point to 10.5.2. Check the advisory yourself before you close the ticket.
The CVSS vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H. It needs a user to visit a page, but no privileges on the attacker's side.
How to check if you're exposed
Find the version of every Dozzle container you run. If you start it from an image, list the images and tags:
docker ps --format '{{.Names}} {{.Image}}' | grep -i dozzle
docker image ls amir20/dozzle
A tag of latest tells you nothing, so compare the image digest or the version shown in the Dozzle interface with release 10.5.2. If you pin a tag in compose files, search your repositories for it.
What to do now
- Upgrade every Dozzle instance to 10.5.2 or later and recreate the container.
- Check who can reach Dozzle. Do not run it on a host that also serves untrusted pages on a sibling subdomain or on localhost.
- Review which users are authorized for exec and attach, and trim that list.
- Ask whether Dozzle needs shell access at all in your setup, and turn it off where it does not.
- Add Dozzle to your dependency and image inventory so the next release is tracked.
Why it matters
The class is CWE-346, origin validation error. The WebSocket upgrader accepted any origin, and the login cookie used SameSite Lax. The advisory points out that SameSite works at the site level, not the origin level. A page on a sibling subdomain, or another service on localhost, can therefore open a socket that carries the victim's valid cookie.
The result, per the record, is an interactive shell in any container the victim is authorized to reach. The KEV flag is false and I found no statement that this is exploited in the wild. Still, container shells are a high-value target, so patch promptly.
Quick check
Does SameSite Lax cookie protection stop this?
No. The advisory notes that SameSite compares sites, not origins, so a same-site page on a different origin can still send the cookie. The origin check on the WebSocket upgrade is what fixes it.
Sources
Last reviewed: 19 October 2026.
