Hi.Events validates webhook destination URLs only during registration using a hostname resolution check that blocks private and reserved IP ranges. However, this check does not occur at dispatch time, allowing an attacker to register a public hostname that redirects to internal or cloud metadata addresses. Because the webhook dispatch service follows redirects by default and does not revalidate the destination, it can be coerced into sending requests to internal services. The responses from these internal requests are logged and returned via the webhook logs endpoint, enabling an attacker to read internal service responses. The vulnerability affects version 1.11.1-beta, which fixes the issue by revalidating URLs at dispatch, pinning validated addresses, checking all redirect hops, and handling IPv6 transition addresses correctly.

An attacker can exploit this SSRF vulnerability to make the Hi.Events server send HTTP requests to internal or cloud metadata endpoints that are normally inaccessible externally. This can lead to unauthorized disclosure of sensitive internal information because the internal service responses are stored and returned to the attacker through the webhook logs endpoint. The vulnerability has a high severity score (CVSS 8.4) due to the potential for sensitive data exposure without requiring user interaction or privileges beyond low privileges.

No official patch or remediation level is explicitly stated in the vendor advisory data. However, version 1.11.1-beta includes fixes that revalidate webhook URLs at dispatch, pin validated addresses, check every redirect hop, and decode IPv6 transition addresses to prevent bypasses. Users should upgrade to this fixed version or later if available. Patch status is not yet confirmed — check the vendor advisory for current remediation guidance.