Background
WebHookAlertNotifyHandlerImpl.send (hertzbeat-alerter/.../WebHookAlertNotifyHandlerImpl.java:42-72) issues a server-side POST to a user-supplied hookUrl (e.g. via POST /api/notice/receiver/send-test-msg) after only a non-blank check — no scheme or address filtering, and the outbound auth header is caller-controlled. The same pattern applies to other user-configurable webhook base URLs (Ntfy/Gotify).
I reported this privately to the ASF security team. They assessed it as within the documented trusted-user model (a URL configured by a highly-trusted user), so it is not a vulnerability, and suggested filing here as hardening.
Suggested hardening
- Before sending, resolve the host and reject loopback / link-local (169.254.0.0/16, fe80::/10) / RFC-1918 / ULA addresses — check the resolved IP, and re-check on redirects.
- Restrict the scheme to http/https.
- Apply the same guard to the other user-set webhook base URLs.
Happy to send a PR.
Background
WebHookAlertNotifyHandlerImpl.send(hertzbeat-alerter/.../WebHookAlertNotifyHandlerImpl.java:42-72) issues a server-sidePOSTto a user-suppliedhookUrl(e.g. viaPOST /api/notice/receiver/send-test-msg) after only a non-blank check — no scheme or address filtering, and the outbound auth header is caller-controlled. The same pattern applies to other user-configurable webhook base URLs (Ntfy/Gotify).I reported this privately to the ASF security team. They assessed it as within the documented trusted-user model (a URL configured by a highly-trusted user), so it is not a vulnerability, and suggested filing here as hardening.
Suggested hardening
Happy to send a PR.