amir20 Dozzle webhook SSRF guard bypass can reach blocked local targets

Dozzle is a realtime log viewer for docker containers. From 10.5.2 until 10.6.15, the isBlockedIP SSRF guard in internal/notification/dispatcher/webhook.go, used by safeDialContext for webhook notification URLs, does not inspect IPv4 addresses embedded in 6to4, NAT64, Teredo, or IPv4-compatible IPv6 addresses, allowing an authenticated user to reach loopback or link-local targets that the guard intends to block. This issue is fixed in version 10.6.15.

• Product: amir20 Dozzle, specifically the webhook notification dispatcher.
• Documented interval: the narrative description identifies the vulnerable interval as beginning at 10.5.2 and continuing through versions before 10.6.15.
• Structured affected fact: the affected-product record marks < 10.6.15 as affected, but its version field does not independently state 10.5.2 as the lower boundary. Exposure in releases earlier than 10.5.2 is therefore not clearly established by the narrative description.
• Fixed release: 10.6.15. The release notes and security commit inspected during research show that this release includes the change blocking IPv6 transition addresses in the webhook SSRF guard.
• The GitHub advisory inspected during research still displays v10 as affected and no patched version, which conflicts with the structured record, release notes, and security commit. The status of branches or releases outside the stated boundaries remains unverified.

The flaw is in isBlockedIP within internal/notification/dispatcher/webhook.go, which safeDialContext uses before opening connections for the webhook HTTP client. The guard checks loopback, link-local, multicast, unspecified, and selected unroutable IPv4 addresses, but does not inspect IPv4 values embedded inside IPv6 transition addresses.

The missed forms include 6to4, NAT64, Teredo, and IPv4-compatible IPv6 addresses. As a result, an IPv6 address can appear non-blocked even when it represents an embedded IPv4 loopback or link-local address. The fix extracts embedded IPv4 addresses and applies the existing blocking checks to them, including NAT64 local-use addresses and the obfuscated IPv4 client value in Teredo addresses.

An attacker needs an authenticated Dozzle account with permission to configure a webhook URL and a notification trigger for the path to execute. The network conditions required for each transition mechanism to route to a local target can vary by deployment and are not fully established by the public evidence.

The attack path is network-reachable and requires an authenticated Dozzle user who can configure notification webhooks. The supplied assessment characterizes the path as low complexity, requiring low privileges and no separate interaction from another user after the webhook has been configured.

An authenticated user can set a webhook URL containing an IPv6 transition address and wait for a notification to trigger the request. safeDialContext resolves the address and checks it through isBlockedIP, but the vulnerable logic can allow a connection to an embedded loopback or link-local target.

The record marks public exploit status as true, and the project advisory contains proof-of-concept material. The supplied evidence does not name a campaign, victim, or specific exploitation activity outside testing.

Technically, the flaw turns the webhook dispatcher into an SSRF path that can reach loopback and link-local services through IPv6 transition addresses. The primary effect is on confidentiality because potential targets include internal services and cloud metadata endpoints; actual data exposure depends on response handling, network routing, and the permissions of the target service.

Authentication and webhook configuration privileges are required, so this is not an unauthenticated remote path. The record does not establish a direct integrity or availability effect. Because the advisory says the response body is only logged at debug level, the path may be semi-blind, with the returned status code providing the main feedback to the attacker.

RFC 1918 private addresses are intentionally allowed by the guard, so the issue should not be interpreted as access to every private network. Practical exploitability also depends on whether the deployment can route or otherwise support the relevant 6to4, NAT64, or Teredo mechanism.

• An authenticated Dozzle user may be able to use the webhook client as a proxy to restricted loopback services or link-local endpoints.
• If a cloud metadata service is reachable through a link-local address, the request could expose workload information or credentials, depending on infrastructure configuration and the privileges attached to those credentials.
• The advisory describes a semi-blind SSRF: the webhook response body is logged at debug level but is not returned directly to the user, while the status code is returned. This can limit direct data retrieval but still provide connection feedback.
• The guard intentionally permits RFC 1918 ranges for self-hosted webhook targets, so the issue specifically concerns blocked ranges such as loopback and link-local addresses rather than every private network address.
• The record does not establish a direct integrity or availability impact.

1. Upgrade Dozzle to exactly 10.6.15, which the record and release notes identify as containing the webhook SSRF guard fix.
2. Check deployment inventory to ensure that no instance remains within the documented affected interval, and verify that the deployed artifact contains the IPv6 transition address handling change. Do not infer the status of a parallel branch solely from the fix in 10.6.15.
3. If an upgrade cannot be completed immediately, restrict permission to create or modify webhook notification URLs and apply outbound network controls that prevent the Dozzle process from reaching loopback, link-local, and cloud metadata endpoints. These are defense-in-depth precautions, not a vendor-confirmed replacement for the fix.
4. Review existing webhook URLs for IPv6 transition addresses that can represent blocked targets, then retest after upgrading. The supplied sources do not document a specific temporary vendor workaround.

• Inventory amir20 Dozzle deployments, identify whether webhook notifications are enabled, and review which users can create or modify webhook URLs.
• Review webhook URLs for 6to4, NAT64, Teredo, or IPv4-compatible IPv6 addresses, especially where the embedded IPv4 value represents a loopback or link-local target.
• Inspect internal/notification/dispatcher/webhook.go in source or deployed artifacts to confirm that embedded IPv4 values are extracted and rechecked instead of only applying predicates directly to the IPv6 address.
• Review network telemetry for the Dozzle process making webhook connections to loopback, link-local, or cloud metadata endpoints through IPv6 addresses. This is precautionary monitoring, not a confirmed IOC.
• If debug logging is enabled, review webhook-related records for response bodies and request status. Absence of log evidence does not prove that the deployment is safe.