CVE-2026-76838 in Hi.Events
Summary
by MITRE • 08/24/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/24/2026
The vulnerability described constitutes a Server-Side Request Forgery (SSRF) flaw within the webhook management subsystem of the application, specifically affecting versions prior to 1.11.1-beta. The core technical deficiency lies in the timing and scope of input validation for webhook destination URLs. During the registration phase, the system employs a custom validator rule that utilizes PHP's gethostbyname function to resolve hostnames against private IP ranges and reserved address spaces. This check is designed to prevent internal network access by rejecting any hostname that resolves to an RFC 1918 private range or other restricted addresses. However, this validation is performed exclusively at the time of registration and is not enforced during the actual execution phase when webhooks are dispatched. Consequently, a malicious actor can register a webhook with a public domain name that initially passes the security check but later resolves to an internal IP address through DNS manipulation or configuration changes on the target host.
The operational impact of this design flaw is significant because it allows for unauthorized access to internal services and cloud metadata endpoints. When the WebhookDispatchService processes outgoing requests, it relies on the spatie/laravel-webhook-server package without applying additional security constraints such as disabling HTTP redirects by default. Since no custom Guzzle options are configured in backend/config/webhook-server.php to restrict redirect following, the server will automatically follow any 3xx redirection responses issued by the target host. An attacker can therefore register a webhook pointing to an external service that responds with a redirect location targeting loopback addresses like localhost or private network ranges such as 10.x.x.x or 192.168.x.x. Upon dispatch, the server follows this redirect and issues requests to internal resources that are otherwise inaccessible from the public internet. This behavior is further exacerbated by the fact that DNS resolution occurs dynamically at request time rather than being pinned to a specific IP address during registration, allowing for post-registration exploitation via DNS record updates.
The consequences of successful exploitation extend beyond mere network access due to how response data is handled within the application architecture. The WebhookResponseHandlerService captures and stores the body content returned by the internal service in webhook logs. Subsequently, the WebhookLogResource exposes this stored data through a publicly accessible webhook logs endpoint. This creates a direct information disclosure vector where an attacker can read sensitive responses from internal services simply by observing the log entries generated after triggering the malicious webhook dispatch. Unlike blind SSRF scenarios where only network connectivity is confirmed, this implementation allows for readable exfiltration of internal application states, configuration details, or cloud metadata credentials that might be exposed by backend APIs or infrastructure components responding to the forged requests. Both event and organizer webhooks are affected as they share the same validation rule and dispatch path, expanding the attack surface across multiple functional areas of the platform.
From a classification perspective, this vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF) due to the server making HTTP requests on behalf of users without sufficient restrictions on destination addresses. It also relates to CWE-602 Client-Side Injection for Untrusted Data if one considers the input validation failure as a form of injection into the request flow, though SSRF is the primary classification. In terms of MITRE ATT&CK framework techniques, this maps to T1571 Non-Standard Port Communication and potentially T1098 Account Manipulation or data exfiltration pathways depending on what internal services are accessed. The failure to validate input at execution time rather than just creation time is a common pattern in SSRF vulnerabilities where developers assume that initial sanitization provides sufficient protection against dynamic network changes.
Mitigation strategies must address both the validation logic and the HTTP client configuration. As implemented in version 1.11.1-beta, the most effective remediation involves revalidating the webhook destination URL at the moment of dispatch rather than relying solely on registration-time checks. This ensures that any DNS resolution performed during execution reflects current network states and prevents exploitation via post-registration DNS changes. Additionally, the system should pin the validated IP address or enforce strict allow-listing based on resolved IPs to prevent domain hijacking attacks. It is critical to configure the underlying HTTP client library, such as Guzzle in this Laravel-based application, to disable automatic redirect following by default. If redirects are necessary for legitimate business logic, they must be manually controlled with explicit checks at each hop to ensure no internal addresses are accessed. Furthermore, IPv6 transition mechanisms like mapped IPv4 addresses should be explicitly decoded and validated against private ranges, as these can sometimes bypass standard regex or IP comparison filters that do not account for such encoding variations. Finally, limiting the exposure of webhook log contents ensures that even if an SSRF is attempted, sensitive internal responses are not inadvertently leaked through public-facing endpoints.