Background
The generic webhook notification channel (edict/backend/app/channels/webhook.py) currently validates the configured URL only for scheme. Any operator who can edit the notification webhook in the dashboard config can therefore point it at internal addresses (loopback, RFC1918, link-local) and have the server POST to them on each scheduled push.
Proposal
Tighten WebhookChannel.validate_webhook to additionally require that the destination resolves exclusively to public IP addresses, and re-validate at send time as defence-in-depth. This brings the generic webhook channel in line with what most notification frameworks do (e.g. blocking 169.254.169.254 and similar) and removes a small but real internal-probing primitive.
I have a fix prepared and will open a PR shortly that references this issue. Happy to share the underlying analysis privately (per SECURITY.md) if preferred — let me know.
Background
The generic webhook notification channel (
edict/backend/app/channels/webhook.py) currently validates the configured URL only for scheme. Any operator who can edit the notification webhook in the dashboard config can therefore point it at internal addresses (loopback, RFC1918, link-local) and have the server POST to them on each scheduled push.Proposal
Tighten
WebhookChannel.validate_webhookto additionally require that the destination resolves exclusively to public IP addresses, and re-validate at send time as defence-in-depth. This brings the generic webhook channel in line with what most notification frameworks do (e.g. blocking 169.254.169.254 and similar) and removes a small but real internal-probing primitive.I have a fix prepared and will open a PR shortly that references this issue. Happy to share the underlying analysis privately (per SECURITY.md) if preferred — let me know.