CVE-2026-45298: Dozzle Auth Bypass Vulnerability

CVE-2026-45298 Overview

Dozzle is a realtime log viewer for Docker containers. Versions prior to 10.5.2 expose an unauthenticated Server-Side Request Forgery (SSRF) vulnerability in the POST /api/notifications/test-webhook endpoint. In a default deployment without DOZZLE_AUTH_PROVIDER configured, the endpoint accepts an attacker-controlled URL and forwards HTTP requests through the Dozzle server. The WebhookDispatcher sends an HTTP POST with attacker-supplied headers and returns the response status code plus up to 1MB of the response body when the target replies with a non-2xx status. The vulnerability is tracked as [CWE-918] and is fixed in version 10.5.2.

Critical Impact

Unauthenticated attackers can pivot through Dozzle to reach internal services, cloud metadata endpoints, and other network resources, exfiltrating up to 1MB of response data per request.

Affected Products

• Dozzle versions prior to 10.5.2
• Default deployments without DOZZLE_AUTH_PROVIDER configured
• Containerized Docker log viewer instances exposed to untrusted networks

Discovery Timeline

• 2026-05-26 - CVE-2026-45298 published to NVD
• 2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-45298

Vulnerability Analysis

The vulnerability resides in Dozzle's notification testing functionality. The POST /api/notifications/test-webhook route is registered without an authentication middleware when no auth provider is configured. The documented quickstart deployment leaves DOZZLE_AUTH_PROVIDER unset, making this the default state for most installations.

When a request reaches the endpoint, the supplied URL and request headers flow into the WebhookDispatcher. The dispatcher performs an outbound HTTP POST from the Dozzle process itself. The response status code is returned to the caller, and when the target returns a non-2xx response, up to 1MB of the response body is also relayed back. This gives an attacker both blind and partially semi-blind SSRF primitives.

Root Cause

The root cause is missing authorization on a sensitive administrative endpoint combined with insufficient URL validation. The handler does not restrict destinations to a whitelist, does not block internal address ranges such as 127.0.0.0/8, 169.254.169.254, 10.0.0.0/8, or 192.168.0.0/16, and does not strip or constrain user-controlled headers.

Attack Vector

The attack vector is network-based and requires no privileges or user interaction. An attacker sends a crafted POST request to /api/notifications/test-webhook with a JSON body specifying an internal target URL. The Dozzle server then issues the outbound request from its own network context. Attackers can target cloud instance metadata services to retrieve temporary credentials, probe internal Docker socket endpoints, scan internal HTTP services by inferring status codes, and exfiltrate up to 1MB of any non-2xx response body. Because Dozzle typically runs alongside Docker with elevated container visibility, the blast radius extends into adjacent container infrastructure.

No verified public exploit code is available. See the GitHub Security Advisory GHSA-3v9w-6365-9w54 for technical details.

Detection Methods for CVE-2026-45298

Indicators of Compromise

• HTTP POST requests to /api/notifications/test-webhook from unexpected source IPs or without prior authenticated session activity
• Outbound connections from the Dozzle container to internal RFC1918 ranges, link-local addresses such as 169.254.169.254, or loopback interfaces
• Webhook test requests containing target URLs pointing to cloud metadata endpoints or internal service ports
• Anomalous outbound traffic volumes from the Dozzle process correlating with inbound API calls

Detection Strategies

• Inspect reverse proxy and ingress logs for POST /api/notifications/test-webhook requests, particularly from external networks
• Correlate inbound API calls with outbound HTTP traffic originating from the Dozzle container to detect SSRF relay patterns
• Alert on any Dozzle outbound connection attempts to cloud metadata IPs or internal management interfaces

Monitoring Recommendations

• Enable verbose access logging on the Dozzle endpoint and forward logs to a centralized SIEM for correlation
• Deploy network policies that log and alert on egress from the Dozzle container to non-approved destinations
• Track Dozzle version inventory across environments and flag any instance running below 10.5.2

How to Mitigate CVE-2026-45298

Immediate Actions Required

• Upgrade Dozzle to version 10.5.2 or later immediately, referencing the GitHub Release v10.5.2
• Configure DOZZLE_AUTH_PROVIDER to enforce authentication on all API endpoints, even if upgrading is delayed
• Restrict network exposure of Dozzle to trusted management networks only, never the public internet
• Audit logs for prior calls to /api/notifications/test-webhook and review outbound connections from Dozzle hosts

Patch Information

The maintainers released version 10.5.2 to remediate the SSRF flaw. The fix introduces authentication enforcement on the test-webhook endpoint. Refer to GitHub Security Advisory GHSA-3v9w-6365-9w54 for the complete remediation details.

Workarounds

• Place Dozzle behind a reverse proxy that enforces authentication and blocks /api/notifications/test-webhook until upgrade is complete
• Apply container-level egress firewall rules to deny outbound traffic from Dozzle to internal address ranges and cloud metadata endpoints
• Run Dozzle on an isolated network segment with no route to sensitive internal services or instance metadata services

# Block Dozzle egress to cloud metadata and internal ranges (example iptables rules)
iptables -I DOCKER-USER -s <dozzle_container_ip> -d 169.254.169.254 -j DROP
iptables -I DOCKER-USER -s <dozzle_container_ip> -d 10.0.0.0/8 -j DROP
iptables -I DOCKER-USER -s <dozzle_container_ip> -d 192.168.0.0/16 -j DROP

# Enforce authentication on Dozzle deployment
docker run -e DOZZLE_AUTH_PROVIDER=simple \
  -e DOZZLE_USERNAME=admin \
  -e DOZZLE_PASSWORD=<strong_password> \
  amir20/dozzle:10.5.2