CVE-2026-108602 in Helicone
Summary
by MITRE • 10/10/2026
Helicone through v2025.08.21-1 contains a server-side request forgery vulnerability in the Jawn webhook sender that allows authenticated organization users to reach internal services by using hostnames resolving to private addresses. Attackers can create webhooks with public hostnames that resolve or DNS-rebind to loopback or internal addresses, causing blind POST requests to internal HTTPS services.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/10/2026
The vulnerability identified in Helicone versions up to 2025.08.21-1 represents a critical server-side request forgery flaw within the Jawn webhook sender component. This security defect allows authenticated organization users, who possess valid credentials and appropriate permissions within the application, to manipulate outbound HTTP requests initiated by the system. By crafting malicious webhook configurations that specify target hostnames resolving to private or loopback IP addresses, an attacker can force the Helicone server to send POST requests to internal services that are otherwise inaccessible from external networks. This capability effectively bypasses network-level access controls and firewalls, as the request originates from a trusted internal source rather than directly from the internet-facing interface of the application.
The technical mechanism behind this exploitation relies on DNS rebinding or direct IP resolution manipulation. When an authenticated user creates a webhook payload, they can specify a destination URL that points to localhost or other private network ranges such as 10.x.x.x, 172.16.x.x through 172.31.x.x, or 192.168.x.x. Because the Helicone server processes these requests internally without validating whether the resolved IP address falls within a safe public range, it proceeds to establish an HTTPS connection with the internal service. The attacker can then inject specific HTTP headers and body content into this blind POST request, potentially triggering actions on vulnerable internal APIs, administrative interfaces, or microservices that rely solely on network segmentation for protection against unauthorized access.
The operational impact of this vulnerability is significant, particularly in environments where Helicone serves as a central hub for managing API traffic and observability data. An attacker with authenticated access can use this flaw to probe the internal network topology, identify sensitive services such as database management consoles, cloud provider metadata endpoints, or other microservices running on non-standard ports. By sending crafted requests, an adversary might attempt to exploit secondary vulnerabilities in these internal applications, escalate privileges by interacting with administrative APIs, or exfiltrate data if those internal services are misconfigured and allow unauthorized write operations. This transforms a standard authentication boundary into a pivot point for deeper network intrusion, undermining the principle of least privilege and compromising the integrity of the entire infrastructure segment behind Helicone.
This vulnerability aligns closely with CWE-918, which describes Server-Side Request Forgery (SSRF), specifically falling under the subcategory where flaws allow access to internal resources via DNS rebinding or direct IP specification. In terms of offensive security frameworks, this behavior corresponds to MITRE ATT&CK technique T1557, Adversary-in-the-Middle, as it facilitates man-in-the-middle attacks by intercepting and manipulating traffic between the Helicone server and internal services. It also relates to T1046, Network Service Discovery, if used for scanning purposes, or T1098, Account Manipulation, if leveraged to alter configurations of connected systems through forged requests.
To mitigate this risk, immediate remediation should involve updating Helicone to a version later than 2025.08.21-1 where the webhook sender has been patched with strict IP allowlisting or deny-listing mechanisms that block private address ranges. In the interim, organizations should implement network-level controls such as egress filtering on the Helicone server’s outbound traffic to prevent connections to non-public IP spaces. Additionally, deploying a reverse proxy in front of internal services can enforce additional authentication checks independent of source IP addresses, ensuring that even if an SSRF attack succeeds, the target service rejects unauthorized requests. Regular auditing of webhook configurations and restricting webhook creation privileges to only those users who absolutely require such functionality will further reduce the attack surface associated with this vulnerability.