Description

Hi.Events validates a webhook destination only when it is registered, never when it is used. NoInternalUrlRule in backend/app/Validators/Rules/NoInternalUrlRule.php resolves the hostname with gethostbyname() and rejects private and reserved ranges, which any public hostname passes. At dispatch, WebhookDispatchService takes the stored URL and calls it through spatie/laravel-webhook-server without repeating the check, and backend/config/webhook-server.php sets no Guzzle options, so redirect following remains enabled by default. A destination that answers with a redirect to a loopback, private or cloud metadata address therefore causes the server to issue that request, and changing the hostname's DNS record after registration reaches the same result because no resolution is repeated. The response is not discarded: WebhookResponseHandlerService stores the body on the webhook log and WebhookLogResource returns it from the webhook logs endpoint, so the requester reads what the internal service replied rather than inferring it. Both event and organizer webhooks share the rule and the dispatch path. Version 1.11.1-beta revalidates at dispatch, pins the validated address, checks every redirect hop, and decodes IPv6 transition addresses that previously bypassed the filter.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.5",
  "pubDate": "2026-08-24T18:17:22.363Z",
  "pubdate": "2026-08-24T18:17:22.363Z",
  "executiveSummary": "Hi.Events suffers from a Server-Side Request Forgery (SSRF) vulnerability that allows attackers to interact with internal network resources, loopback addresses, and cloud metadata services. The vulnerability arises due to insufficient validation of webhook destinations, where validation occurs exclusively during initial registration rather than at the time of event dispatch.\nThe affected product is Hi.Events, specifically versions prior to 1.11.1-beta. The root cause involves the NoInternalUrlRule located in backend/app/Validators/Rules/NoInternalUrlRule.php, which utilizes gethostbyname() to filter out private and reserved IP ranges only upon registration. Furthermore, the underlying HTTP client configuration via spatie/laravel-webhook-server does not disable redirect following in backend/config/webhook-server.php.\nAn attacker with the capability to register or modify webhook destinations can exploit this flaw by providing a public hostname that subsequently responds with an HTTP redirect pointing to internal resources (such as 127.0.0.1 or cloud metadata endpoints) or by altering the DNS records of a registered hostname post-validation. Because WebhookDispatchService initiates requests without re-validating destinations or checking redirect hops, and because WebhookResponseHandlerService logs and exposes the response body via WebhookLogResource, an attacker can successfully read the contents of internal service responses.\nThe risk is critical as it permits unauthorized internal network reconnaissance, data exfiltration from cloud metadata APIs, and potential interaction with internal services otherwise shielded from external networks.",
  "technicalDetails": "The vulnerability exists within the webhook registration and dispatch mechanism of Hi.Events. During the registration phase, backend/app/Validators/Rules/NoInternalUrlRule.php resolves the provided hostname using gethostbyname() to evaluate whether the resulting IP address falls within private or reserved network ranges. Any public hostname successfully bypasses this initial restriction.\nThe primary root cause of the vulnerability is the lack of validation persistence and the absence of re-evaluation during the dispatch phase. When an event triggers a webhook, WebhookDispatchService retrieves the stored URL and invokes it using the spatie/laravel-webhook-server package without repeating the IP validation checks. Additionally, backend/config/webhook-server.php configures the underlying Guzzle HTTP client without disabling redirect following.\nAttackers can execute exploitation through two primary vectors. First, an attacker can supply a benign public hostname that responds with an HTTP redirection status code directing the client to internal assets, loopback addresses, or cloud metadata endpoints. Second, an attacker can register a valid public hostname and subsequently modify its DNS A or AAAA records to resolve to internal IP addresses after the registration validation has already passed.\nAs the WebhookDispatchService dispatches the request, the HTTP client automatically follows the redirect chain to the internal target. Because intermediate redirect hops are not inspected and IPv6 transition addresses previously bypassed filtering mechanisms, the server issues requests to restricted network spaces. Furthermore, IPv6 transition formats were previously capable of bypassing the initial filter.\nOnce the internal resource processes the forged request, WebhookResponseHandlerService captures the resulting response body and stores it within the webhook log. The application then exposes this data through WebhookLogResource via the webhook logs endpoint, allowing the requester to directly read the response data returned by internal services rather than merely inferring success or failure.\nBoth event and organizer webhooks share this vulnerable rule and dispatch path, amplifying the attack surface. Authentication and privilege requirements depend on the ability to register or configure webhooks within the application."
}