CVE-2026-44985 Overview
CVE-2026-44985 is a Cross-Site WebSocket Hijacking (CSWSH) vulnerability in Dozzle, a realtime log viewer for Docker containers. Versions prior to 10.5.2 configure the WebSocket upgrader for the /exec and /attach endpoints with CheckOrigin: func(r *http.Request) bool { return true }, accepting upgrade requests from any origin. Combined with a JWT session cookie issued with SameSite: Lax, an attacker controlling a same-site origin can hijack the victim's authenticated session. The flaw is tracked under CWE-346: Origin Validation Error and is fixed in version 10.5.2.
Critical Impact
An attacker can obtain interactive shell access inside any Docker container the victim user is authorized to access, leading to full integrity loss on managed workloads.
Affected Products
- Dozzle versions prior to 10.5.2
- Dozzle /exec WebSocket endpoint
- Dozzle /attach WebSocket endpoint
Discovery Timeline
- 2026-05-26 - CVE-2026-44985 published to NVD
- 2026-05-26 - Last updated in NVD database
Technical Details for CVE-2026-44985
Vulnerability Analysis
Dozzle exposes WebSocket endpoints at /exec and /attach to provide interactive container shells and log attachment. The server upgrades incoming WebSocket requests using a CheckOrigin callback that unconditionally returns true. This disables the browser-side origin check that normally protects WebSocket handshakes from cross-origin abuse.
Authentication relies on a JWT stored in a cookie with the SameSite=Lax attribute. Lax cookies are attached to top-level cross-site requests, and the WebSocket handshake initiated from a same-site origin carries the cookie automatically. An attacker who controls any same-site origin, such as a sibling subdomain or another service bound to localhost, can therefore open an authenticated WebSocket back to the Dozzle instance from a victim's browser.
Once the channel is established, the attacker proxies commands through the hijacked socket and receives shell output, achieving interactive code execution inside containers the victim can reach.
Root Cause
The root cause is missing origin validation on the WebSocket upgrade handler combined with a permissive cookie SameSite policy. The CheckOrigin function should compare the Origin header against an allowlist of trusted hosts. Returning a constant true removes that boundary entirely.
Attack Vector
Exploitation is network-based and requires no privileges or user interaction beyond visiting an attacker-controlled page on a same-site origin. The attacker page issues a new WebSocket() call to the Dozzle /exec endpoint. The browser includes the victim's JWT cookie, the handshake succeeds, and the attacker script reads and writes container shell traffic. See the GitHub Security Advisory GHSA-j643-x8pv-8m67 for the upstream technical description.
Detection Methods for CVE-2026-44985
Indicators of Compromise
- WebSocket handshake requests to /exec or /attach whose Origin header does not match the canonical Dozzle hostname.
- Successful container exec sessions initiated immediately after a user loaded an unrelated same-site web page.
- Unexpected shell processes such as /bin/sh or /bin/bash spawned inside containers correlated with Dozzle WebSocket sessions.
Detection Strategies
- Inspect Dozzle access logs for WebSocket upgrades where the Origin header is absent or differs from the deployed Dozzle FQDN.
- Correlate authenticated JWT sessions with the source Referer and Origin of WebSocket handshakes to flag cross-origin reuse.
- Monitor Docker daemon audit events for exec API calls originating from the Dozzle service account outside of normal operator windows.
Monitoring Recommendations
- Forward Dozzle reverse-proxy logs into a centralized log platform and alert on /exec or /attach upgrades with foreign Origin values.
- Baseline container exec activity per user and alert on volume spikes or off-hours sessions.
- Track installed Dozzle versions across hosts and alert when any instance reports a version lower than 10.5.2.
How to Mitigate CVE-2026-44985
Immediate Actions Required
- Upgrade all Dozzle deployments to version 10.5.2 or later, which adds proper Origin validation on the WebSocket upgrader.
- Invalidate existing JWT sessions and rotate the Dozzle JWT signing secret to revoke any hijacked tokens.
- Restrict network exposure of Dozzle to trusted administrative networks or a VPN until the upgrade is complete.
Patch Information
The vendor fixed this issue in Dozzle 10.5.2. Release notes and signed artifacts are available at the GitHub Dozzle Release v10.5.2 page. The fix enforces an Origin allowlist on the /exec and /attach WebSocket handlers.
Workarounds
- Place Dozzle behind a reverse proxy that rejects WebSocket upgrade requests whose Origin header does not match the Dozzle hostname.
- Serve Dozzle from a dedicated apex domain isolated from any other user-controlled subdomains to neutralize same-site cookie reuse.
- Configure the upstream session cookie to SameSite=Strict where deployment permits, preventing cross-site WebSocket handshakes from carrying credentials.
# Example NGINX reverse-proxy snippet enforcing Origin allowlist
map $http_origin $dozzle_origin_ok {
default 0;
"https://dozzle.example.com" 1;
}
server {
listen 443 ssl;
server_name dozzle.example.com;
location ~ ^/(exec|attach) {
if ($dozzle_origin_ok = 0) { return 403; }
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_pass http://dozzle_upstream;
}
}
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


