Technical impact
Hi.Events verifies a webhook destination only when the webhook is first registered. The validation routine resolves the hostname and rejects private or reserved ranges, but the resolution is performed only once and any public hostname passes. When the webhook is later dispatched, the stored URL is called through the spatie/laravel-webhook-server library without repeating the host check, and Guzzle’s default configuration allows redirects to be followed. If the destination URL or one of its redirect hops points to a loopback, private, or cloud metadata address, the server will issue a request to that internal host. The response from the internal service is not discarded; it is logged by the WebhookResponseHandlerService and made available through the webhook logs endpoint, effectively leaking the internal content to the entity that requested the logs.
Affected Systems
Hi.Events is compromised in all releases before 1.11.1-beta; both event and organizer webhook routes use the same validation and dispatch logic. The affected vendor is HiEventsDev, and the mechanism is implemented across all webhook endpoints that rely on the spatie/laravel-webhook-server library.
Risk and Exploitability
The CVSS score of 8.4 classifies this flaw as high severity, although no EPSS score is published and it is not listed in the CISA KEV catalog. The likelihood of exploitation depends on an attacker’s ability to register or modify a webhook destination; the vendor’s documentation implies that authenticated users can create or update webhooks, so the likely attack surface is through such authenticated access, which is an inference based on the description. Once a malicious URL is registered, the server will perform the internal request, log the response, and expose it via the logs endpoint. The vendor’s 1.11.1-beta release revalidates URLs at dispatch, pins the validated address, checks each redirect hop, and disables unsafe IPv6 transition addresses, thereby eliminating the attack path.
