CVE-2026-76838
HighCVSS 8.5Exploitation Probability (EPSS)
Low risk23th percentile - higher than 23% of all known CVEs
Summary
Hi.Events validates a webhook destination only when it is registered, never when it is used. NoInternalUrlRule 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 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. 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.
Risk Assessment
The risk includes the possibility of sending requests to internal services such as cloud metadata, potentially leading to disclosure of sensitive data or privilege escalation.
Recommendation
It is recommended to immediately upgrade Hi.Events to version 1.11.1-beta or later and implement additional security controls for webhooks.
Other vulnerabilities in Hi.Events
See all- CVE-2026-60119Medium
A cross-site scripting vulnerability in Hi.Events before 1.11.0 allows authenticated attackers with event creation or edit permissions to inject arbitrary HTML and JavaScript by embedding a malicious event title containing the </script> sequence, which is not escaped by JSON.stringify() when embedded in inline script tags. Attackers can craft an event title that breaks out of the script context in the application/ld+json structured data block or server-side rehydrated state, causing the payload to execute in the browser of any user who views the public event page, including unauthenticated visitors and authenticated administrators.
- CVE-2026-60118Medium
A vulnerability in Hi.Events before version 1.11.0 allows unauthenticated attackers to purchase hidden tickets by referencing their IDs in order creation requests due to missing server-side authorization checks. Attackers can enumerate sequential hidden ticket IDs from visible ones and buy VIP, invite-only, or discounted tickets not intended for public sale.
- CVE-2026-57960Medium
A vulnerability in Hi.Events up to version 1.9.0 allows unauthorized access to attendee lists via public check-in list endpoints. Using only the short_id, an attacker can retrieve full attendee data including emails and personal information, as well as create or delete check-in records without authentication.
- CVE-2026-57959Medium
A vulnerability in Hi.Events through version 1.9.0 allows unlimited use of limited promo codes. The validation checks the usage count before the asynchronous UpdateEventStatisticsJob increments it, enabling attackers to sequentially reserve multiple orders with the same code, each seeing usage_count=0, and then complete them all at a discounted price.
Original NVD description (English source)
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.