CVE-2026-76838: Hi.Events SSRF Vulnerability

CVE-2026-76838 Overview

CVE-2026-76838 is a Server-Side Request Forgery (SSRF) vulnerability in Hi.Events, an open-source event management platform. The flaw resides in the webhook dispatch pipeline, where the NoInternalUrlRule validator checks destination URLs only at registration time. At dispatch, WebhookDispatchService reuses the stored URL through spatie/laravel-webhook-server with Guzzle's default redirect-following enabled, allowing redirects to loopback, private, or cloud metadata endpoints. Response bodies are stored on the webhook log and exposed through WebhookLogResource, letting an authenticated attacker read internal service responses. The issue is fixed in version 1.11.1-beta.

Critical Impact
An authenticated user with webhook creation privileges can exfiltrate cloud instance metadata credentials and internal service responses by pointing a webhook at an attacker-controlled host that redirects to internal addresses.

Affected Products

Hi.Events versions prior to 1.11.1-beta
backend/app/Validators/Rules/NoInternalUrlRule.php validator component
WebhookDispatchService and WebhookResponseHandlerService dispatch paths

Discovery Timeline

2026-08-24 - CVE-2026-76838 published to NVD
2026-08-27 - Last updated in NVD database

Technical Details for CVE-2026-76838

Vulnerability Analysis

The vulnerability is a classic time-of-check to time-of-use (TOCTOU) SSRF combined with unfiltered redirect handling [CWE-918]. When a user registers a webhook, NoInternalUrlRule resolves the hostname with gethostbyname() and rejects private and reserved IPv4 ranges. Any public hostname passes this initial check and is stored in the database.

At dispatch, WebhookDispatchService fetches the stored URL and hands it to spatie/laravel-webhook-server. The configuration file backend/config/webhook-server.php sets no Guzzle options, so allow_redirects remains enabled by default. When the attacker-controlled destination replies with an HTTP 3xx redirect to 127.0.0.1, 169.254.169.254, or an internal RFC1918 address, the server follows it. WebhookResponseHandlerService then stores the response body on the webhook log, and WebhookLogResource returns it through the webhook logs API endpoint. Both event webhooks and organizer webhooks share this vulnerable path.

Root Cause

The validator runs once, at registration, and the address is never pinned. DNS records for the registered hostname can change between validation and dispatch, and no revalidation occurs on redirect hops. IPv6 transition addresses such as IPv4-mapped and 6to4 forms bypass the IPv4-only filter entirely.

Attack Vector

An authenticated user registers a webhook pointing at a public host they control. When Hi.Events dispatches the webhook, the attacker's server responds with a 302 redirect to an internal target. Guzzle follows the redirect, the internal service replies, and the response body is persisted to the webhook log where the attacker retrieves it.

php

// Security patch introducing dedicated exception for unsafe URLs
// Source: https://github.com/HiEventsDev/Hi.Events/commit/cfbf468bb5b1
<?php

declare(strict_types=1);

namespace HiEvents\Exceptions;

class UnsafeWebhookUrlException extends BaseException {}

The fix in 1.11.1-beta revalidates URLs at dispatch, pins the validated address, checks every redirect hop, and decodes IPv6 transition addresses that previously bypassed the filter.

Detection Methods for CVE-2026-76838

Indicators of Compromise

Webhook log entries containing response bodies that resemble cloud metadata responses, such as JSON with AccessKeyId, SecretAccessKey, or Token fields from 169.254.169.254.
Outbound HTTP requests from the Hi.Events backend to loopback (127.0.0.0/8), link-local (169.254.0.0/16), or RFC1918 ranges following a webhook dispatch event.
Webhook destinations whose DNS A records changed shortly after registration or that consistently return HTTP 301/302 responses.

Detection Strategies

Correlate webhook creation events with subsequent egress traffic; flag any dispatch where the resolved IP at request time differs from the IP at registration time.
Inspect stored webhook_logs records for response bodies containing internal hostnames, private IP literals, or metadata service identifiers.
Monitor the Hi.Events backend for Guzzle requests whose final target address falls within reserved ranges.

Monitoring Recommendations

Enable request logging in the Hi.Events backend and forward logs to a SIEM for correlation of webhook events with network egress.
Alert on any egress from application servers to 169.254.169.254, the AWS, GCP, and Azure metadata endpoints.
Review webhook usage per tenant and baseline expected destination domains.

How to Mitigate CVE-2026-76838

Immediate Actions Required

Upgrade Hi.Events to version 1.11.1-beta or later, which revalidates at dispatch and pins the resolved address across redirect hops.
Audit existing webhook destinations and delete entries pointing to unknown or newly registered domains.
Review historical webhook_logs records for response bodies exposing internal data or credentials.

Patch Information

The fix is delivered in commit cfbf468bb5b1 via GitHub Pull Request #1311. See the VulnCheck Advisory on Hi.Events for additional context, and the GitHub Repository for Hi.Events for release notes.

Workarounds

Block egress from Hi.Events backend hosts to loopback, RFC1918, link-local, and cloud metadata addresses at the network layer.
Use Instance Metadata Service Version 2 (IMDSv2) on AWS to require session tokens that Guzzle will not supply.
Disable webhook creation for untrusted users until the upgrade is applied by restricting the relevant role permissions.

bash

# Example iptables rules restricting Hi.Events backend egress to metadata and private ranges
iptables -A OUTPUT -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -d 192.168.0.0/16 -j REJECT